perm filename F76.IN[LET,JMC] blob
sn#259352 filedate 1977-01-16 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00350 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00031 00002 ∂24-SEP-76 1136 AJT
C00036 00003 ∂27-SEP-76 0919 REG
C00038 00004 ∂27-SEP-76 1016 FTP:BUCHANAN at SUMEX-AIM Weizenbaum reviews
C00039 00005 ∂28-SEP-76 1002 FTP:KEITH UNCAPHER ACCOUNT ON KL-20
C00040 00006 ∂28-SEP-76 2137 RDR LSI's and Advanced Tech.
C00042 00007 ∂28-SEP-76 2155 RDR location
C00043 00008 ∂29-SEP-76 0012 DCL v. Henke
C00044 00009 ∂29-SEP-76 0158 RDR Sipb@mit
C00046 00010 ∂29-SEP-76 1100 RDR via AMET SIPB@SU
C00049 00011 ∂29-SEP-76 1140 RDR via AMET sipb
C00050 00012 ∂29-SEP-76 1703 FTP:Jonathan Day (DAY @ MIT-MC)
C00052 00013 ∂30-SEP-76 1256 REG
C00053 00014 ∂04-OCT-76 1559 LES New Ampex Interface
C00054 00015 ∂04-OCT-76 2131 AJT
C00055 00016 ∂05-OCT-76 1352 RDR via AMET Memorial Auditorium
C00056 00017 ∂06-OCT-76 1240 TOB proposal with Lockheed
C00057 00018 ∂06-OCT-76 2224 REG via AMET
C00059 00019 ∂07-OCT-76 0214 LES Dialnet
C00060 00020 ∂07-OCT-76 1126 BG
C00061 00021 ∂07-OCT-76 1219 REG
C00064 00022 ∂07-OCT-76 2328 RDR timetable
C00065 00023 ∂07-OCT-76 2355 RDR Text editing system for university
C00069 00024 ∂08-OCT-76 0104 RPG BBPP
C00071 00025 ∂08-OCT-76 0143 RDR via AMET
C00072 00026 ∂08-OCT-76 0143 RDR via AMET delays
C00074 00027 ∂08-OCT-76 0958 REG
C00075 00028 ∂08-OCT-76 1441 PLW Address change
C00076 00029 ∂08-OCT-76 1551 CG Blackboard translator
C00077 00030 ∂08-OCT-76 1938 MRC via RTGT DFTP
C00080 00031 ∂08-OCT-76 2327 RDR via AMET Documenttattion
C00081 00032 ∂09-OCT-76 0003 RDR via AMET Status report
C00082 00033 ∂09-OCT-76 0058 ME Jungle time
C00083 00034 ∂09-OCT-76 1229 RDR via AMET cliquism
C00084 00035 ∂09-OCT-76 1240 RDR via AMET bouncingg keys
C00085 00036 ∂09-OCT-76 1441 RDR via AMET
C00086 00037 ∂09-OCT-76 1508 RDR
C00089 00038 ∂09-OCT-76 1915 REG
C00090 00039 ∂10-OCT-76 1233 BG
C00091 00040 ∂11-OCT-76 1016 FTP:TAYNAI at SUMEX-AIM Calendar Items
C00092 00041 ∂11-OCT-76 1155 PAW lib.bib
C00094 00042 ∂11-OCT-76 1853 FTP:FEIGENBAUM at SUMEX-AIM mannna
C00095 00043 ∂12-OCT-76 0853 FTP:RAJ REDDY(A610RR29) at CMUB CMU'S KL-20
C00097 00044 ∂12-OCT-76 1301 DEW paper on your tablee
C00098 00045 ∂12-OCT-76 1408 RDR via AMET tools for terminal assembly
C00099 00046 ∂12-OCT-76 1900 RWW
C00100 00047 ∂12-OCT-76 1910 RDR via AMET
C00101 00048 ∂12-OCT-76 1912 RDR via AMET
C00105 00049 ∂13-OCT-76 1101 JMC*
C00107 00050 ∂13-OCT-76 1330 REG
C00108 00051 ∂13-OCT-76 1400 JMC*
C00109 00052 ∂13-OCT-76 1413 LES NXL account
C00110 00053 ∂13-OCT-76 1428 REM via AMET
C00111 00054 ∂13-OCT-76 1416 REM via AMET SPEED COMPARISON OF DATACOMPUTER AND CRUNCHING
C00114 00055 ∂13-OCT-76 1646 MS
C00115 00056 ∂13-OCT-76 1859 REM via AMET
C00116 00057 ∂14-OCT-76 0924 QIB Meeting with Bob Calfee
C00117 00058 ∂14-OCT-76 1050 JB dinner.
C00118 00059 ∂14-OCT-76 1238 RDR via AMET
C00121 00060 ∂14-OCT-76 1526 FTP:MRC at MIT-AI (Mark Crispin ) DFTP version 2
C00123 00061 ∂14-OCT-76 1537 MS SEMINAR NOTICE
C00124 00062 ∂14-OCT-76 1607 100 : Queenie 1976-77 Faculty/Staff Directory
C00125 00063 ∂14-OCT-76 1404 JMC
C00127 00064 ∂14-OCT-76 1923 RDR via AMET LOTS location
C00129 00065 ∂14-OCT-76 1931 RDR via AMET $$
C00130 00066 ∂14-OCT-76 1944 RDR via AMET
C00131 00067 ∂14-OCT-76 1935 RDR via AMET update
C00133 00068 ∂14-OCT-76 1953 RDR via AMET PROJEC.DIS[LOT,RDR]
C00136 00069 ∂14-OCT-76 1938 JMC
C00137 00070 ∂14-OCT-76 2140 RDR via AMET SIGUCC meeting
C00138 00071 ∂14-OCT-76 2141 RDR via AMET Academic Council (?) mailingg list
C00139 00072 ∂14-OCT-76 2223 RDR via AMET
C00141 00073 ∂14-OCT-76 2307 JMC
C00142 00074 ∂15-OCT-76 1058 RDR
C00143 00075 ∂15-OCT-76 1100 JMC*
C00144 00076 ∂15-OCT-76 1100 RDR
C00145 00077 ∂15-OCT-76 1502 100 : QIB
C00146 00078 ∂15-OCT-76 1920 RDR
C00147 00079 ∂15-OCT-76 1921 RDR via AMET 303
C00150 00080 ∂16-OCT-76 1732 LSP LISP
C00151 00081 ∂16-OCT-76 1859 DCL
C00152 00082 ∂16-OCT-76 2332 RDR via AMET Computer Group meeting
C00153 00083 ∂16-OCT-76 2350 RDR via AMET New network port for the ISI DECsystem-20
C00154 00084 ∂17-OCT-76 1309 FTP:FEINLER at OFFICE-1 Re: Stanford network addresses
C00156 00085 ∂17-OCT-76 2149 RDR via AMET storage
C00157 00086 ∂18-OCT-76 1057 PAW
C00179 00087 ∂18-OCT-76 2215 FTP:MRC at MIT-AI (Mark Crispin ) DFTP
C00181 00088 ∂19-OCT-76 1333 RDR via AMET SCIP TRAN
C00182 00089 ∂19-OCT-76 1415 RDR via AMET Provost should pay
C00186 00090 ∂19-OCT-76 1858 JB thesis.
C00187 00091 ∂19-OCT-76 2011 RDR Status Report
C00189 00092 ∂19-OCT-76 2122 RDR
C00190 00093 ∂19-OCT-76 2303 RDR via AMET 3 things
C00193 00094 ∂20-OCT-76 0949 REG
C00194 00095 ∂20-OCT-76 1147 TOB conf
C00195 00096 ∂20-OCT-76 1304 RDR via AMET Terminals in dorms
C00196 00097 ∂20-OCT-76 2157 EHF via AMET CABLE RUNNING
C00198 00098 ∂20-OCT-76 2220 RDR via AMET
C00199 00099 ∂21-OCT-76 2311 RDR
C00200 00100 ∂22-OCT-76 0847 RDR via AMET cable situation
C00204 00101 ∂22-OCT-76 1006 RDR The LOTS advisory board:
C00206 00102 ∂22-OCT-76 1635 RDR
C00213 00103 ∂22-OCT-76 1805 ZM
C00214 00104 ∂22-OCT-76 1925 RDR via AMET CS105/6
C00217 00105 ∂23-OCT-76 2127 REG
C00218 00106 ∂24-OCT-76 0022 RDR
C00220 00107 ∂24-OCT-76 1309 REG
C00221 00108 ∂24-OCT-76 1415 SAU via AMET Room 303
C00223 00109 ∂24-OCT-76 1624 REG Budget
C00224 00110 ∂24-OCT-76 1701 REG
C00225 00111 ∂24-OCT-76 1735 JMC
C00226 00112 ∂24-OCT-76 2015 RDR via AMET budget
C00228 00113 ∂24-OCT-76 2036 RDR via AMET why not list the A-board members in BLURB?
C00229 00114 ∂25-OCT-76 1442 RWW AI memo containing proofs
C00230 00115 ∂25-OCT-76 1552 JB
C00232 00116 ∂25-OCT-76 2129 100 : RWW CONDITIONAL EXPRESSIONS
C00233 00117 ∂26-OCT-76 0522 GFF via SRI
C00234 00118 ∂27-Oct-76 1400 REG
C00235 00119 ∂27-Oct-76 1939 BG Syntactic simplification
C00236 00120 ∂27-Oct-76 1942 RWW IF THEN ELSE
C00237 00121 ∂27-Oct-76 1945 RCB Thesis
C00238 00122 ∂27-Oct-76 2229 BG Syntactic simplification documentation
C00239 00123 ∂28-Oct-76 1537 HVA Telephone Call from Martin Davis
C00240 00124 ∂28-Oct-76 2037 RPG NCOMPLR
C00241 00125 ∂28-Oct-76 2212 RDR machine & documentation
C00242 00126 ∂28-Oct-76 2306 RDR via AMET
C00243 00127 ∂29-Oct-76 0325 FTP:MRC at MIT-AI (Mark Crispin ) SAIL DFTP
C00245 00128 ∂29-Oct-76 1101 RPG GRIND
C00246 00129 ∂29-Oct-76 1824 RPG BIBOPIZATION
C00247 00130 ∂29-Oct-76 2140 FTP:MRC at MIT-AI (Mark Crispin ) Good news and bad
C00250 00131 ∂29-Oct-76 2138 JAB via TYMT terminal
C00252 00132 ∂30-Oct-76 0153 LES
C00253 00133 ∂30-Oct-76 0255 LES
C00256 00134 ∂30-Oct-76 1241 JAB via TYMT terminal
C00257 00135 ∂30-Oct-76 1920 RDR terminal rental
C00259 00136 ∂01-Nov-76 0149 FTP:Wiederhold at SUMEX-AIM NSF Proposal
C00277 00137 ∂01-Nov-76 1020 REG
C00279 00138 ∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
C00280 00139 ∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
C00281 00140 ∂01-Nov-76 2201 RPG BIBOP
C00282 00141 ∂01-Nov-76 2312 RDR via AMET jordan quad
C00285 00142 ∂01-Nov-76 2324 RDR via AMET communication
C00286 00143 ∂02-Nov-76 0102 CG midterm solutions
C00287 00144 ∂02-Nov-76 2109 RDR
C00288 00145 ∂02-Nov-76 2112 RDR Provost
C00291 00146 ∂02-Nov-76 2154 JMC
C00294 00147 ∂03-Nov-76 0037 JAB via TYMT terminal rental
C00297 00148 ∂03-Nov-76 1335 LES
C00298 00149 ∂04-Nov-76 0024 FTP:MOON5 at MIT-MC (David A. Moon )
C00299 00150 ∂04-Nov-76 1352 RDR via AMET our ENCRYPTED source tape
C00300 00151 ∂04-Nov-76 1813 DSB
C00303 00152 ∂05-Nov-76 0105 RDR via AMET terminal renttal
C00305 00153 ∂05-Nov-76 0138 RDR via AMET XGP
C00311 00154 ∂05-Nov-76 2225 RDR via IMSSSS SCIP
C00313 00155 ∂06-Nov-76 1539 REG
C00314 00156 ∂07-Nov-76 0511 RDR
C00321 00157 ∂09-Nov-76 0018 RDR The 20 appears to be here
C00322 00158 ∂09-Nov-76 1417 PAW todorovich visit
C00323 00159 ∂09-Nov-76 1535 RDR via AMET machine is here!!
C00325 00160 ∂09-Nov-76 2311 PMF
C00326 00161 ∂10-Nov-76 1113 CCG Juan Ludlow
C00327 00162 ∂10-Nov-76 1351 RPG PROGV Feature
C00329 00163 ∂10-Nov-76 1439 LES Dialnet
C00330 00164 ∂10-Nov-76 1450 CET via SUMX Bank Account
C00331 00165 ∂10-Nov-76 2129 MRC via RTGT NEW DFTP TO NEW DATACOMPUTER
C00334 00166 ∂11-Nov-76 0808 JRA
C00335 00167 ∂11-Nov-76 1415 DCO corky's thesis
C00336 00168 ∂11-Nov-76 1526 RDR
C00337 00169 ∂11-Nov-76 1536 MRC via RTGT NDFTP
C00338 00170 ∂11-Nov-76 1623 RDR via AMET terminals in SCRDT lobby
C00339 00171 ∂11-Nov-76 1817 REG
C00341 00172 ∂12-Nov-76 0903 JBR
C00342 00173 ∂12-Nov-76 0956 HVA Texas Instruments Portable Data Terminal
C00343 00174 ∂12-Nov-76 1209 RDR via AMET CMU-20
C00344 00175 ∂12-Nov-76 1438 LES Ed Parker account
C00345 00176 ∂12-Nov-76 2150 JFR Sail manual
C00346 00177 ∂12-Nov-76 2346 RWW conditionals
C00347 00178 ∂13-Nov-76 1014 JBR
C00356 00179 ∂13-Nov-76 1021 REG
C00357 00180 ∂13-Nov-76 1755 LES Puritanism
C00358 00181 ∂13-Nov-76 1839 FTP:FEINLER at OFFICE-1 Request for your ideas
C00363 00182 ∂14-Nov-76 1207 RDR via AMET EDUCOM
C00364 00183 ∂14-Nov-76 1500 RDR
C00366 00184 ∂14-Nov-76 1507 RDR
C00367 00185 ∂15-Nov-76 1204 PAW
C00368 00186 ∂15-Nov-76 1523 FTP:JAB at MIT-AI (John A. Borchek )
C00369 00187 ∂15-Nov-76 1619 100 : jab via AMET
C00370 00188 ∂16-Nov-76 1627 MDD Minimal model of set theory
C00372 00189 ∂17-Nov-76 0702 JAB via TYMT
C00373 00190 ∂17-Nov-76 0706 JAB via TYMT discussion
C00374 00191 ∂17-Nov-76 2052 EJG DD channel spy
C00376 00192 ∂18-Nov-76 1713 EJG DD channel spy
C00378 00193 ∂18-Nov-76 1907 REG
C00379 00194 ∂18-Nov-76 2020 RDR via AMET location problem
C00386 00195 ∂18-Nov-76 2057 RDR via AMET NEWS
C00387 00196 ∂19-Nov-76 1147 TW talking
C00388 00197 ∂19-Nov-76 1843 FTP:MRC at MIT-AI (Mark Crispin ) ITS NDFTP, documentation...
C00390 00198 ∂22-Nov-76 0001 RDR via AMET 303 location
C00393 00199 ∂22-Nov-76 1029 RWW FOL
C00394 00200 ∂22-Nov-76 1150 FTP:GJS at MIT-AI (Gerald Jay Sussman )
C00396 00201 ∂22-Nov-76 1224 FTP:GJS at MIT-AI (Gerald Jay Sussman )
C00397 00202 ∂22-Nov-76 2120 SAU via AMET Terminal location(s)
C00398 00203 ∂23-Nov-76 1400 JMC*
C00399 00204 ∂23-Nov-76 1900 JMC*
C00400 00205 ∂23-Nov-76 2322 RWW BUG
C00402 00206 ∂24-Nov-76 1518 RPG Debug/Step (SAIL)
C00403 00207 ∂24-Nov-76 1937 RWW BUG
C00404 00208 ∂24-Nov-76 2207 PMF TTY11
C00405 00209 ∂25-Nov-76 0213 REM at TTY11 0213
C00406 00210 ∂25-Nov-76 0331 REM via AMET Dialer
C00407 00211 ∂25-Nov-76 1506 BPM Service level
C00408 00212 ∂25-Nov-76 2244 FTP:MRC at MIT-AI (Mark Crispin ) ITS DFTP
C00410 00213 ∂26-Nov-76 1257 FTP:MRC at MIT-AI (Mark Crispin )
C00411 00214 ∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
C00412 00215 ∂26-Nov-76 2119 FTP:MRC at MIT-AI (Mark Crispin ) New DFTP from CCA
C00414 00216 ∂26-Nov-76 2128 FTP:MRC at MIT-AI (Mark Crispin ) correction
C00415 00217 ∂26-Nov-76 2208 FTP:MRC at MIT-AI (Mark Crispin ) DCSTAT PROGRAM
C00416 00218 ∂27-Nov-76 2154 JMC bug in spindl
C00417 00219 ∂28-Nov-76 1602 FTP:MRC at MIT-AI (Mark Crispin )
C00418 00220 ∂29-Nov-76 1219 100 : Queenie Trip to Las Vegas
C00419 00221 ∂29-Nov-76 1303 FTP:MRC at MIT-AI (Mark Crispin )
C00420 00222 ∂29-Nov-76 1422 RWW Dan Blum (DSB)
C00421 00223 ∂30-Nov-76 0308 LES Farrel
C00422 00224 ∂30-Nov-76 0313 LES
C00423 00225 ∂30-Nov-76 0909 CCG farrell
C00424 00226 ∂30-Nov-76 1245 RWW
C00425 00227 ∂30-Nov-76 1401 DCL
C00426 00228 ∂30-Nov-76 1410 DCL
C00427 00229 ∂01-Dec-76 0959 CCG pub
C00428 00230 ∂01-Dec-76 1618 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) SCHEME
C00431 00231 ∂01-Dec-76 1649 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) scheme
C00432 00232 ∂02-Dec-76 0048 CG write up on knowledge and ignorance
C00433 00233 ∂02-Dec-76 0646 FTP:GJS at MIT-AI (Gerald Jay Sussman )
C00434 00234 ∂02-Dec-76 0704 FTP:GJS at MIT-AI (Gerald Jay Sussman )
C00435 00235 ∂02-Dec-76 0953 PAT
C00436 00236 ∂02-Dec-76 1432 RPG
C00437 00237 ∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
C00438 00238 ∂02-Dec-76 2230 MRB via MAXC Display proposal
C00441 00239 ∂03-Dec-76 1048 CCG Nishino
C00443 00240 ∂03-Dec-76 2332 FTP:MRC at MIT-AI (Mark Crispin ) For your information
C00450 00241 ∂06-Dec-76 1100 JMC*
C00451 00242 ∂07-Dec-76 0018 FTP:MRC at MIT-AI (Mark Crispin )
C00453 00243 ∂07-Dec-76 1033 LES For your consideration.
C00454 00244 ∂07-Dec-76 2307 DCL
C00456 00245 ∂08-Dec-76 0103 REM via AMET
C00457 00246 ∂08-Dec-76 1100 JMC*
C00458 00247 ∂08-Dec-76 1438 MFB SAMEF
C00459 00248 ∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
C00462 00249 ∂08-Dec-76 2120 FTP:CARL at MIT-AI (Carl Hewitt )
C00467 00250 ∂09-Dec-76 0110 CG BB
C00468 00251 ∂09-Dec-76 0154 FTP:Geoff at SRI-AI FYI
C00477 00252 ∂09-Dec-76 1040 RPG SAMEFRINGE
C00478 00253 ∂09-Dec-76 1405 RDR via AMET <mccarthy>taskss@LOTS
C00480 00254 ∂09-Dec-76 1611 ND samefringe vs flatten
C00481 00255 ∂11-Dec-76 0124 LES BUREAU.1
C00483 00256 ∂11-Dec-76 1636 FTP:MINSKY at MIT-AI (Marvin Minsky )
C00484 00257 ∂12-Dec-76 2135 MFB SAME FR
C00485 00258 ∂12-Dec-76 2332 MFB SAMEFR
C00486 00259 ∂13-Dec-76 0245 DCL
C00487 00260 ∂13-Dec-76 1138 RWW CONDITIONAL EXPRESSIONS
C00488 00261 ∂13-Dec-76 1406 RWW CONDITIONAL EXPRESSIONS
C00489 00262 ∂13-Dec-76 2202 REG
C00490 00263 ∂13-Dec-76 2340 DCL
C00491 00264 ∂14-Dec-76 1050 REP CS-258
C00492 00265 ∂14-Dec-76 2113 FTP:MRC at MIT-AI (Mark Crispin )
C00493 00266 ∂14-Dec-76 2221 RPG Printing windows/SAIL
C00494 00267 ∂15-Dec-76 0017 NS
C00495 00268 ∂16-Dec-76 1547 RPG
C00497 00269 ∂17-Dec-76 1632 MDD Minimal entailment
C00498 00270 ∂19-Dec-76 2004 LES
C00499 00271 ∂21-Dec-76 0017 LES Pressburger
C00500 00272 ∂21-Dec-76 0043 FTP:MRC at MIT-AI (Mark Crispin ) New versions of DFTP and DCSTAT
C00501 00273 ∂21-Dec-76 0907 PMF Datamedia simulator for imlacs
C00502 00274 ∂21-Dec-76 1037 FTP:ERDA at BBN-TENEX Second Berkeley Workshop
C00507 00275 ∂21-Dec-76 1230 DPB
C00508 00276 ∂21-Dec-76 1357 LES
C00510 00277 ∂22-Dec-76 0209 RDR via AMET LOTS status report
C00513 00278 ∂22-Dec-76 1100 JMC*
C00514 00279 ∂22-Dec-76 1204 TW via MAXC Sam's affair
C00522 00280 ∂22-Dec-76 1252 DPB TA for cs258
C00524 00281 ∂23-Dec-76 1214 TW via MAXC
C00525 00282 ∂23-Dec-76 1354 TW via MAXC more thoughts on Partee's example
C00537 00283 ∂23-Dec-76 1401 TW via MAXC addendum
C00538 00284 ∂24-Dec-76 0249 PMF
C00539 00285 ∂24-Dec-76 1242 JAB via AMET accounting
C00541 00286 ∂27-Dec-76 2123 TOG ACCOUNTS
C00542 00287 ∂28-Dec-76 0029 TOG ACCOUNTS
C00544 00288 ∂28-Dec-76 1059 FTP:Nilsson at SRI-AI proposed seminar
C00548 00289 ∂28-Dec-76 1212 RDR
C00556 00290 ∂28-Dec-76 1215 RDR via AMET
C00557 00291 ∂28-Dec-76 1634 PMF
C00558 00292 ∂28-Dec-76 1954 RDR via AMET
C00559 00293 ∂29-Dec-76 0134 PMF Typing <call> at an Imlac.
C00560 00294 ∂29-Dec-76 1114 FTP:Nilsson at SRI-AI Seminar on SRI-AI Research
C00565 00295 ∂30-Dec-76 1450 LES
C00568 00296 ∂30-Dec-76 1550 DON JARGON guests
C00569 00297 ∂30-Dec-76 1911 WP Winter term:
C00570 00298 ∂31-Dec-76 2044 WP CS390
C00571 00299 ∂31-Dec-76 2110 PMF
C00572 00300 ∂01-Jan-77 0217 PMF <ctrl><break>
C00573 00301 ∂01-Jan-77 0226 PMF reloading an imlac.
C00574 00302 ∂01-Jan-77 0352 JAB new spy
C00575 00303 ∂01-Jan-77 0402 JAB new spy
C00576 00304 ∂01-Jan-77 1733 LES
C00577 00305 ∂03-Jan-77 1045 PMF
C00578 00306 ∂03-Jan-77 1629 FTP:Dbrown at SUMEX-AIM Re: MCCARTHY TEACHING SCHEDULE REARRANGEMENT
C00579 00307 ∂03-Jan-77 1917 ME
C00580 00308 ∂03-Jan-77 2140 REM via AMET Heavy use in Dec., light use forthcoming.
C00581 00309 ∂04-Jan-77 0404 PMF
C00582 00310 ∂04-Jan-77 0515 PMF Imlac documentation
C00583 00311 ∂04-Jan-77 1530 RWW FOL
C00584 00312 ∂04-Jan-77 2103 TED
C00585 00313 ∂05-Jan-77 0924 FTP:Nilsson at SRI-AI Problem Solving Seminar
C00586 00314 ∂05-Jan-77 1154 DCO
C00588 00315 ∂05-Jan-77 1544 FTP:Buchanan at SUMEX-AIM Computer Forum this month
C00590 00316 ∂06-Jan-77 1539 LES Home phone lines
C00593 00317 ∂06-Jan-77 1929 FTP:ELLENBY at PARC-MAXC Returned Your call
C00595 00318 ∂07-Jan-77 1159 PMF
C00596 00319 ∂08-Jan-77 2331 RWW conditional
C00597 00320 ∂08-Jan-77 2340 RWW conditional substitution
C00598 00321 ∂09-Jan-77 0727 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00600 00322 ∂10-Jan-77 0033 RWW
C00601 00323 ∂10-Jan-77 1441 JBR
C00602 00324 ∂10-Jan-77 1552 RPG
C00604 00325 ∂11-Jan-77 1015 RWW FOL
C00605 00326 ∂11-Jan-77 1016 RWW FOL
C00606 00327 ∂11-Jan-77 1311 FTP:Boyer at SRI-AI Our new theorem prover
C00611 00328 ∂11-Jan-77 1910 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00618 00329 ∂11-Jan-77 2020 FTP:Boyer at SRI-AI Meeting
C00620 00330 ∂12-Jan-77 1005 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00624 00331 ∂12-Jan-77 1054 FTP:Moore at SRI-AI Our recent proof
C00626 00332 ∂12-Jan-77 1348 CJS
C00627 00333 ∂12-Jan-77 2235 DSB
C00628 00334 ∂13-Jan-77 0132 JMC
C00630 00335 ∂13-Jan-77 0150 CLT mix
C00631 00336 ∂13-Jan-77 1600 FTP:MRC at MIT-AI (Mark Crispin )
C00633 00337 ∂13-Jan-77 2138 DCL MEETING ON NEW LISP PROVER
C00634 00338 ∂13-Jan-77 2318 FTP:Moore at SRI-AI Re: MEETING ON NEW LISP PROVER
C00636 00339 ∂13-Jan-77 2332 LES CSDDIS.PRO
C00637 00340 ∂13-Jan-77 2348 LES CSDDIS
C00638 00341 ∂14-Jan-77 0210 LES
C00639 00342 ∂14-Jan-77 0631 LES Display proposal
C00640 00343 ∂14-Jan-77 1405 LES
C00641 00344 ∂14-Jan-77 1452 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00642 00345 ∂14-Jan-77 1609 FTP:PRATT at MIT-AI (Vaughan Pratt )
C00649 00346 ∂15-Jan-77 1426 DCO MEETING
C00650 00347 ∂15-Jan-77 1522 LES LSPLUG
C00651 00348 ∂15-Jan-77 1532 LES Feinler request
C00652 00349 ∂15-Jan-77 1923 FTP:Boyer at SRI-AI meeting
C00655 00350 ∂15-Jan-77 2214 DEK
C00658 ENDMK
C⊗;
∂24-SEP-76 1136 AJT
My exam: Serra House Conference room at 10, Sept. 28 confirmed
∂27-SEP-76 0919 REG
The proposed schedule for Cedar Hall, as I remember it, was roughly:
4 weeks for planning (by Carlos Abrahams & Assoc, Palo Alto)
2 weeks for review of plan & changes
1 week to incorporate the changes in the plan
1 week to show location of work to various contractors
2 weeks to allow bids
1 week to negotiate contract with lowest bidder
12 week delay to obtain air conditioning unit
4 weeks in construction
total 27 weeks = nearly 7 months.
It would be possible to overlap several activities. The a/c could be
ordered now, or at least at the end of the planning stage, for instance.
Assuming that 12 weeks is right for the a/c, we couldn't possibly do
better than 16 weeks total. I am inclined to think that this plan is
ridiculously padded by people who are accustomed to taking their time
about such things. For instance, 4 weeks for construction seems like
too much.
∂27-SEP-76 1016 FTP:BUCHANAN at SUMEX-AIM Weizenbaum reviews
Date: 27 SEP 1976 1014-PDT
From: BUCHANAN at SUMEX-AIM
Subject: Weizenbaum reviews
To: jmc at SU-AI
cc: buchanan
I talked with Joe about our CS memo and he declined our offer to write
responses to Lederberg's and my reviews. So the memo will contain the
three reviews plus Joe's response to you that appeared in SIGART.
Will you send me a copy of Joe's response that we can include?
Did your review appear any place but SIGART that we should mention?
Bruce
-------
Yes, Creative Computing.
∂28-SEP-76 1002 FTP:KEITH UNCAPHER ACCOUNT ON KL-20
Date: 28 SEP 1976 0955-PDT
Sender: JEANNETTE at USC-ISIB
Subject: ACCOUNT ON KL-20
From: KEITH UNCAPHER
To: JMC at SU-AI
Message-ID: <[USC-ISIB]28-SEP-76 09:55:41-PDT.JEANNETTE>
We will try our best to honor your request.
-------
∂28-SEP-76 2137 RDR LSI's and Advanced Tech.
Sure I'll call them but what did Ralph find out from purchasing (there's a
note here on his terminal that Jim Martin called at 3:25 while Ralph was
at Cedar with the site prep people. By the way, the seem thorough and speedy;
we'll see tomorrow about their price. Ralph and I are going to see Esparza
tomorrow at 9. I don't know how switching engineering firms is to be handled
but that could be a time delay if not promptly done also.
I will also come tomorrow AM. We didn't hear from Martin. Please
find out whether double character problem is general or
whether the warranty is to be pursued on this particular terminal.
If we go with Heavey, there won't be separate engineering.
∂28-SEP-76 2155 RDR location
The meeting is in the Economics(?) conference room on the fourth floor of
Encina.
I meant that planning has already retained Carlos Abrahms et al. to do what
we perhaps want Heavey to do.
∂29-SEP-76 0012 DCL v. Henke
To: JMC
I have written a letter to v.Henke telling him of our present
decision not to honor our verbal agreement to him. I must say that
it is one of the most humiliating things I personally have ever
had to do.I have promised him an offer from this Lab. the first
opportunity we can do so. I hope you will both read the letter
and object to it if you feel so inclined before it is sent, or
not objecting, cosequently agree to honor it thereafter.
∂29-SEP-76 0158 RDR Sipb@mit
I asked Ralph about sending a copy to Prof. Adams of LOTS and Prof. Franklin.
The cover letter is in your mailbox, and the file is of course SIPB75.TXT[LOT,RDR].
Fine about SIPB material. I trust you realize the implications
of the fact that LOTS and SIPB don't have the same responsibilities
and resources. Namely, SIPB can devote its resources entirely to
independent student computing. Stanford has merely repackaged the
money and responsibilities and hopes to get independent student
computing as a bonus. This hope is substantially justified, I think,
but at some time new decisions will have to be made about emphasis
and new resources requested if independent student computing is to
get all it might usefully use. I expect this to happen in connection
with disk allocation when disk gets tight and in connection with the
relocation of terminals.
∂29-SEP-76 1100 RDR via AMET SIPB@SU
To: JMC, REG
The lack of separate funding is 50% of the reason I would like to
institute a SIPB rather separattee from LOTS, althhough in close
contact with LOTS. I see where independent student computting is a
logical probability due to LOTS, but as you said itt is nott the same as
SIPB@MIT. Furthermore, nott only could the independent student computing
situation at LOOTS deteriorate (say if control were given to SCIP or
Feigenbaum), but the enttire LOTS idea could be messed up in ways that
a SIPB here could act to prevent, given the right kind of insertion
into tthe University structure. THis is the other 50% of my desire
for a SIPB. That is, student consultants are not onl cheaper than
"professionals" (a la SCIP User "Services"), but are also much bettter,
probably for other typical University computer users besides sttudents too.
So anyway, tthat was the tone of the notte I sent Adams.
LOTS and the SIPB would reinforce each other so tthat tthe combinattion
was greater than the sum of the ttwo parts.
Now, as to sttarting sttudents to work at such a thing, is your message
tto me about the way tthe University is attemptting to get an
independent student computtingg freebie, whereas specific incrreased funding
would be useful, available for me to show people, and mail to @LOTS?
I would be happiest if you would put off trying for an SIPB
until LOTS is functioning and we can see how much of a problem remains.
Nothing will be done seriously until then anyway, and the effect of
such agitation now will be to make the officials worry about whether
they did the right thing in starting LOTS. Others will say, "Look,
the students can't make up their minds what they want; maybe they
just like meetings".
∂29-SEP-76 1140 RDR via AMET sipb
To: JMC, REG
OK, I will only aggitate among students--except for forwarding SIPB information
as already done (I.e., as I encounttered it and thought itt of interest.)
∂29-SEP-76 1703 FTP:Jonathan Day (DAY @ MIT-MC)
Date: 29 SEP 1976 2005-EST
From: Jonathan Day (DAY @ MIT-MC)
To: JMC at SU-AI
Message-ID: <4058.[MIT-MC] 09/29/76 20:05:36>
We are having a seminar here at Johns Hopkins on "Models
of Mind". We are reading Weizenbaums book as well
as Hubert Dreyfus' What Computers Cant Do. Could you give me
pointers to accessible files containing:
1) Your criticisms of Weizenbaum's book
2) His reaction to your criticisms
3) Your comments on Dreyfus' book, if any
4) Any reactions he has sent you
We are also reading Kenneth Sayre's philosophic study
of machine intelligence - it appears to be much more
carefully reasoned than either Dreyfus or Weizenbaum.
The seminar is being led by someone you may know - Steve Kosslyn
who was a grad. student (Psychology) there at Stanford.
Thanks for any help you can give ...
Jonathan Day
net: Day @ MIT-MC
The files weizen.<anything>[pub,jmc] concern the book.
While I have debated with Dreyfus, I have nothing in
writing. The most general statement of my position is
in the review of the Lighthill Report published in the
AI journal.
∂30-SEP-76 1256 REG
To: RDR, JMC
Dave Enman called to say that the terminals are being shipped from
LA to us today. We'll probably get them Friday or (more likely) Monday.
∂04-OCT-76 1559 LES New Ampex Interface
I recently requested permission from Surra to rebuild the New Ampex memory
interface, to provide 6 ports instead of the current 4, at a cost of $5k.
I have just learned (second hand) that he plans to extract a pound of
flesh: if we do it with ARPA money, the memory will belong to ARPA again.
I suggest that we evade this potential problem by using music money.
What say you?
∂04-OCT-76 2131 AJT
Will you be able to spare some time either Tuesday or Wednesday to talk over
Chapters 4 and 5 of my thesis?
Wednesday afternoon
∂05-OCT-76 1352 RDR via AMET Memorial Auditorium
To: REG, JMC
They discovered the roof damage last Friday, and ttoday they have contractors
on the job. We need to invoke tthatt algorithm.
∂06-OCT-76 1240 TOB proposal with Lockheed
Carlstrom is favorable. We will do some
negotiating about funding or other sources
of funding. This would help IPTO to maintain
or increase funding to Stanford.
Tom
∂06-OCT-76 2224 REG via AMET
It looks like the establishment won't let us use
Heavey. It doesn't matter, because even if we did, they'd
wrap him in the standard bureaucratic 7 week delay.
There's a new plan and bid from Carlos Abrahams.
$48K to $53.4K with the higher price for chilled water, but, time
permitting, we should use chilled water.
I have details for you. I'll bring them tomorrow.
I emphasized to Esparza that we should order the long-lead
items now. He approximattely agrees, but wants to do the
revised form 2 before ordering anything. Amy
is cooperative, but she probably can't overturn the planning
office bureaucracy.
What we should do is attempt to further compress the 7 week
startup delay (like to 1 week, or 2 with some overlap
into the construction period). Like there's
still a 4 week pre-design/design stage followed
by a 1 week review and 1 week for changes. It seems to
me that all that should be done in week ending next friday 10/15.
I would hope that we can be allowed to avoid bidding (3 weeks).
While all is not hopeless, relentless pursuit is indicated.
∂07-OCT-76 0214 LES Dialnet
There is a new (final?) version of the Dialnet proposal on your terminal.
The budget is now at $96k for 18 months.
∂07-OCT-76 1126 BG
Richard and I have had some animated discussions about the appropriate FOL
commands for the syntactic simplification routines. I have written up the
results in simpl.txt[doc,bg] and would appreciate any comments you have.
Page 2 is a general discussion of the syntactic simplification algorithm,
and page 3 is the summary of the FOL commands, both the existing commands
and the proposed changes. The names of the commands do not seem
particularly good to me, so if you have any better names, please tell me.
Thank you. Bill
∂07-OCT-76 1219 REG
1. Heavey called again and said that he's passed the license examination
and should recieve official notification by monday. (B1 general contractor's
license). He further says that he can have plans ready on wednesday for our
review. He also suggests that the week planned for review should be changed
to 2 or 3 hours; I agree.
I suggested to Heavey that he call Esparza to inform him of all the above.
I called Amy to tell her too, and to suggest that she encourage Esparza to
follow through. I'm not sure what Esparza's going to do; I'd like for him
to tell Heavey to go ahead and prepare the plans on that schedule.
(Heavey also mentioned that he was arranging to post a bond this week,
but that the completion of that requires the above mentioned notification).
2. Apart from Heavey, Esparza said that Carlos Abrahams could possibly have
their plans by next Friday or the following Monday.
3. Machine room space here is very tight, especially with the musicians bringing
in the Samson box and memory for the PDP-6. SLAC has a machine room with space
for two more 370/168s. I don't know who to approach about using it.
I'm generally opposed to this temporary installation. It looks like a big
nuisance and I'd rather spend the energy in agitating to get Cedar done on
time. Besides which, if it were a good idea to have a 20 to do our software
on, we could probably arrange to get the use of one at DEC. Not so convenient,
but maybe less hassle than dismantling the system (it does have to be taken apart
for shipping and to make it fit into Cedar) and reassembling it.
4. I think I have a suitable plan for putting terminals in Cedar. Have you
seen the new terminal area(s) in Pine? They've installed carpets, which is
a nice touch; I'd be tempted to copy that were it not for the "low overhead".
∂07-OCT-76 2328 RDR timetable
To: JMC, REG
So as to assure as timely an end to site preparation as possible, we
should pin Esparza down as to exactly who has to approve what when.
Should I try to obtain this information from him?
No, we have enough people pursuing him for now.
∂07-OCT-76 2355 RDR Text editing system for university
To: JMC
CC: REG, JAB
I have received a copy of a proposal for funding of such a project from
Jon Day at Hopkins. I only asked for information about their "University
Computer Society" (sort of a cross between LOTS and the Computer Group;
they have responsibility for running the EE department's 11/45 UNIX
system), and he threw in the other information. We seem to be in
a much better situation to ask for such funding than they, and I
know you believe in this idea; so I'll leave the information in your
mailbox. Could I have the originals back please?
Also, I have been contacted by another student at Hopkins who is
distressed by the limited scope of computing at Hopkins and who is
interested in starting a Hopkins LOTS. The 11/45 is small and priorities
are heavily oriented to the EE department which owns it; their University
computing center operates a KI10 for academic use (and a couple of IBM's
for administrative), but it is run like SCIP as far as money to pay for
access goes. They call the KI "Solly's Folly," in honor of Solis James
the director who doesn't understand it and prefers IBM for their
maintenance calls. Also, little staff is devoted to the 10, unlike
SCIP. They already have a free $2/day of computing for students but
20 minutes isn't much and that is all it allows. They will not readily
permit students to use punch cards. Since the 10 there is underutilized,
it would seem they could adopt the LOTS philosophy to great advantage, as
they have already done in the EE department. I'm sending them our blurb,
budget and general information.
A new EE grad student came by the LOTS office today. (He saw blurb posted
in the window.) It seems University of Illinois has a student run
370/158 and he has been baffled by his encounters with the SCIP
situation here--nobody knows anything about the system, he says.
I'll say!
∂08-OCT-76 0104 RPG BBPP
There are really two problems to contend with:
1. Since ILISP does not have stack IO, meaning that one
cannot switch file contexts and successfully return, the BBPP
initializing file loses. It tries to do:
(DSKIN (206 NXL) (BB.LAP))
.
.
(<something that does an INC and a READ>)
(<something that does an INC and a READ>)
.
.
.
But it never gets to the second (<something ...>).
Thus the BB package is never sucessfully initialized.
If I run BB interpreted, with the initialization file
looking like:
(DSKIN (206 NXL) (BB.LSP))
(PROG NIL
.
.
(<something that does an INC and a READ>)
(<something that does an INC and a READ>)
.
.
.
)
Then it works fine.
2. If I try to run it compiled, however, I get a PUSHDOWN
CAPACITY EXCEEDED... And this even though I use bloated
allocations. This implies that the compiled code is losing,
which suggests that the compiler is losing. In addition,
the poor compiler cannot compile BB.LSP!
I'm not sure what should be done about this situation.
-RPG-
∂08-OCT-76 0143 RDR via AMET
delays
∂08-OCT-76 0143 RDR via AMET delays
whatt worries me is tthatt Esparza seems to bee in a position of wantting to
stick with is contractors and defend their delayys as necessary. thus he
is unwilling to push this, as it needs to be, and byy him, or to ask
other university people to push their partt of it. So we hhave
to do tthe pushingg, and it mainlyy involves
each detail of the procedure, from the contractors (except Heavey seems
to push himself) to Plant Services and Busineess and Finance and their
reeviewing. If they say 12 weeks and we cut each item in the estimate
by half through prodding, that is 6 weeks and bearable.
Although eeveryone agreed tthat we should order long lead items
now, no one seems abou to do it!
∂08-OCT-76 0958 REG
I talked with Bill Koteff, DEC 10/20 Educational Marketing person. He's gloomy
about the documentation problem. DEC now has a policy prohibiting reproduction
of their manuals (there are some exceptions, but the excuse that they cost too
much is not acceptable). Bill is still trying to unwedge them.
I'll keep in touch with him, and if he can't budge them soon, I'll ask you
to write to John Leng, or whatever.
He's also trying to get us the tape of TOPS-20 sources, and is checking on that now.
Keep in mind just doing it and letting them sue.
∂08-OCT-76 1441 PLW Address change
To: JMC, QIB
My address and phone number have changed to:
Philip Wadler
P.O. Box 3312
Stanford, CA 94305
(415) 327-6049
∂08-OCT-76 1551 CG Blackboard translator
The working version of the blackboard program may be used by incanting:
(DSKIN (206,CG) BBPP) at IL (it seems to be necessary to allocate 50k or so
for IL). Then DSKIN the files containing the programs you wish to print;
finally (DSKOUT OUTFIL (BBPUB @( <list of EXPRs and FEXPRs to b printed>)))
will result in the PUBable file OUTFIL containing the blackboard notation
for the given EXPRs and FEXPRs.(The file BB.DOC[206,NXL] is still contains
correct information on this matter.)
∂08-OCT-76 1938 MRC via RTGT DFTP
OH, THERE WAS A SYSTEM MESSAGE I PUT UP ABOUT IT A COUPLE OF DAYS
AGO. DFTP IS AN FTP-TO-THE-CCA-DATACOMPUTER PROGRAM. NOT TOO LONG
AGO(END OF AUGUST) I WROTE AN ITS VERSION FOR MIT-AI/ML/MC/DM,
AND JUST THIS WEEK I GOT A SAIL VERSION OF DFTP COMPLETED(SORT OF MY
SAYING "THANK YOU" TO SAIL FOR ACCESS TO THEIR COMPUTER SYSTEM).
THE DATACOMPUTER HAS BEEN DOCUMENTED IN A LOT OF ARPANET PUBLICATIONS,
BUT BASICALLY, IT IS A SYSTEM UNDER CCA-TENEX TO STORE MASSIVE AMOUNTS
OF DATA UNDER AN ADVANCED NODE-HEIRARCHY SYSTEM. IT ALSO HAS THE
CAPABILITY TO DO PROCESSING ON THE DATA. IT IS USED IN VLDB TYPE
STUFF...
DFTP USES THE DATACOMPUTER AS SORT OF A LARGE MAGNETIC TAPE; IE, A
PLACE TO PUT LARGE FILES FOR ARCHIVAL PURPOSES WHERE YOU DON'T HAVE TO
WORRY ABOUT IT GETTING REAPED WHEN DISK SPACE IS LOW OR LOCAL
SECURITY PROBLEMS. IT IS DOCUMENTED IN DFTP.MRC[UP,DOC].
RIGHT NOW, I'VE BEEN PUTTING ALL SAIL PEOPLE ON THE ITS NODE. BUT
LES IS TRYING TO GET CCA TO CREATE A SAIL NODE FOR SAIL PEOPLE.
I HOPE THIS ANSWERS YOUR QUESTION. SORRY I TOOK SO LONG, BUT I HAD
LOGGED OFF BEFORE YOU EVIDENTLY SAY THE MESSAGE. I AM ON A POOR
10CPS TELETYPE AT THE PRESENT AND IT MAKES HACKING PAINFUL(I CAN'T
GET UP TO THE AI LAB AT MIT OFTEN ENOUGH TO SUIT ME!).
MARK
Thanks for the information;I would like to be able to try it.
∂08-OCT-76 2327 RDR via AMET Documenttattion
To: REG, JMC
If DECC won'tt lett us reproduce thheirs, we can creeattee our own,
reproduce it, and publicize itts availabilitty for reproducttion
by others. We can obviously do a bettter job thhan ttheyy; thhis
shhould unsettle tthem.
In general, this is impractical given the manpower we have
available though it might be done for selected topics. However,
it wouldn't unsettle them; they would simply be glad to have
some of their work done for them - unless the documentation
contained some harsh words about the reason.
∂09-OCT-76 0003 RDR via AMET Status report
To: LOTS.DIS[P,DOC]:;
It occurred to me that a status report is long
overdue, especially in view of the complications that have developed
recently.
Basically, there may be a problem in having the
computer room air-condittioning and power ready in time. TThis is
due to bad communicattion between the Provost's Office and tthe Planning
Office and LOTS. Serious work was nott begun earlyy enough.
Forttunatelyy, ttheir is some hope beecause the bureaucracy creattes an
inflatted ordinary schedule that we are ttrying to compact.
A montth or more delay appears in site.
∂09-OCT-76 0058 ME Jungle time
To: LES, JBR, REG, JMC, ME
I would like to make 1700-1900 on Saturday and Sunday be jungle
time just as it already is on Monday through Friday.
∂09-OCT-76 1229 RDR via AMET cliquism
To: JAB, JMC, SAU, RDR, EHF, DSL, DL, MXB, PLH, LPL, REG, FXB, JCF
To: day @ MIT-ML, geoff @ SRI-AI, greg @ SRI-AI
To: hedberg @ SUMEX-AIM
See Halber.msg[LOT,RDR] for some relevant comments on cliquism!
We have to watch that!
∂09-OCT-76 1240 RDR via AMET bouncingg keys
I barely did anything to them (took the tops off) and they seem much better.
That is good, providd they stay this way. It may have been jostling
in transit that did it.
∂09-OCT-76 1441 RDR via AMET
To: JMC, REG
LOTS advisory board meeting apparently occurs this Tuesday at 4 pm.
I hope you knew about it, and certainly wish someone had told
me. Are you coming?
∂09-OCT-76 1508 RDR
To: REG, JMC, RDR
Besides the necessary machine testing and program development, part of
the need for having the system up this quarter is so that there eveolve
students who understand it enough to help others beginning with the
very first quarter of course use by LOTS. Part of that involves the
existence of the central location for them to "hang out " in. (this is
what you imply by deferring remote terminals; even
though I question that means, I agree with the end.)
Anyway, the building is here, so we are free to use it. We can issue keys
and set up reference material about LOTS. We should.
Furthermore, we can put terminals to use and debug that setup, as
well as making them useful. This was suggested at the Computer Group
meeting and I had seriously thought of it before. After seeing
crowded Pine Hall terminals in spie of their recent doubling of
its size, I even more favor it. This is still early in the quarter!
So we run our six line o the TRAN and operate them for a while
as terminals rather than hosts. this would provide six used
ports to place our assembled LSI's on for the acid test.
Additionally, we could connect them to Suppes machine as
replacements for some of the TTY's in use by CS206. If we could
obtain use of Suppes machine for an ad hoc course in PDP-10
machine language, in the vein of CS109 for 370's and CS111 for HP 2100's.
then that would be an additional reason to have Terminals in
Cedar. At the prices Suppes charges for CS206
($50/student-quarter), we should be able to afford this lesser
use.
∂09-OCT-76 1915 REG
Does your message (copied below) refer to RDR's message about
auxiliary consultants for CS 105/106?
∂09-OCT-76 0004 JMC
To: RDR, REG
In general, this is impractical given the manpower we have
available though it might be done for selected topics. However,
it wouldn't unsettle them; they would simply be glad to have
some of their work done for them - unless the documentation
contained some harsh words about the reason.
No! It refers to RDR's message about writing our own versions
of the D.E.C. manuals.
∂10-OCT-76 1233 BG
I borrowed Carl Hewitt's thesis from your office. Bill
∂11-OCT-76 1016 FTP:TAYNAI at SUMEX-AIM Calendar Items
Date: 11 OCT 1976 1016-PDT
From: TAYNAI at SUMEX-AIM
Subject: Calendar Items
To: McCarthy at SU-AI
cc: Taynai
October 24 - 6:00 p.m. cocktails at Rickeys Hyatt House
7:00 p.m. Dinner at Rickeys Hyatt House
October 25 - 6:00 p.m. Cocktails at Faculty Club
October 26 - 9:00 a.m. Serra House - Talk on LOTS
Carolyn Taynai, Secretary to E. Feigenbaum
-------
∂11-OCT-76 1155 PAW lib.bib
lib.bib is in the middle of being completed....the listing of all the reports
should be finished in about two weeks...patte
∂11-OCT-76 1853 FTP:FEIGENBAUM at SUMEX-AIM mannna
Date: 11 OCT 1976 1713-PDT
From: FEIGENBAUM at SUMEX-AIM
Subject: mannna
To: jmc at SU-AI
Thanks for the info? Who says we cant move?
Ed
-------
∂12-OCT-76 0853 FTP:RAJ REDDY(A610RR29) at CMUB CMU'S KL-20
From: RAJ REDDY(A610RR29) at CMUB
Date: 12 Oct 1976 1152 EDT
Subject: CMU'S KL-20
To: MCCARTHY at SU-AI
- - - -
Dear John:
Yes, they are getting a KL-20 for the Computer Center. No, there aren't
many well defined plans yet. The people to contact are Jack McCredie, Director
of the Computer Center, Mike Shamos, John McDermott, and Mary Shaw, all faculty
in the Computer Science Department with primary responsibility for under graduate
education. You might want to send them copies of any plans you may have for the
LOTS system. In the meantime I will mail you whatever material I can find on the present state of planning.
Best regards,
Raj
-------
∂12-OCT-76 1301 DEW paper on your tablee
John, I replaced the former version of my paper on your table with the latest one.
It has 3 positions analyzed. Dave
∂12-OCT-76 1408 RDR via AMET tools for terminal assembly
To: JMC, REG
See tools[lot,rdr].
We have most things now.
∂12-OCT-76 1900 RWW
To: FOL.DIS[FOL,RWW]:;
New FOL feature:
SPOOL <filname>;
XSPOOL <filename>;
spools files directly from FOL. See INFO.FOL[DOC,RWW]. Thank DSB.
∂12-OCT-76 1910 RDR via AMET
To: LOTS.DIS[P,DOC]:;
∂12-OCT-76 1810 JAB via CMUA
did you know tthat the cmu 20 was gotten on some sort of
condition on their evaluating it for educational use. dec
must surely be giving thennm something for that. now
why didnt you think of that
The fact that D.E.C.'s Vice-President for Engineering is a professor
at CMU gives them an in.
∂12-OCT-76 1912 RDR via AMET
To: LOTS.DIS[P,DOC]:;
∂12-OCT-76 1810 JAB via CMUA
did you know tthat the cmu 20 was gotten on some sort of
condition on their evaluating it for educational use. dec
must surely be giving thennm something for that. now
why didnt you think of that
∂13-OCT-76 1101 JMC*
monbec.xgp
∂13-OCT-76 1330 REG
You'd better tell Les to do something to keep NXL from being purged.
Do Something - JMC
∂13-OCT-76 1400 JMC*
Remind Vera to make appointment.
_≡bf5∨π(Z\l@@bPbf∪→∃&@@∪91_AC
G←k]P@@@~) ←Kf↓≥1_A¬GikC1YrAKaSgh}AβhAQQJAi%[JA∩↓eK[←YKHAQ%ZXAQ∀AQCH↓]←hA1←OOK⊂AS\~)gS]G∀ABAs∃CdAC≥↑\@AIk[←d↓QCfA%hAiQ¬hAiQ∀AMSY∃fAS\↓QSfA¬eKBA¬eJAC
ikCY1r~∃s=kef\A∪LAM↑XAo!rA]←PAakh↓iQKZ↓S\A←9JA←L↓s←kd↓CeKCL}~∀~(_≡bf5∨π(Z\l@@bPdp∪%∃~@@AYSBAβ5 (@~) ]&\↓∩AQCYJA
Q OHA
ek]G!KHAM%YJQf$Ai↑A
παAC9HA
Q OHAQQKZA CGVX↓¬∪≥π=~~∃S⊃K]iS
CXXAM↑AgC→JAi↑↓I↑ASP\~∀~( ∂13-OCT-76 1416 REM via AMET SPEED COMPARISON OF DATACOMPUTER AND CRUNCHING
I have been using DFTP and have observed that the datarate is
always between 800 baud and 1700 baud, usually between 1000 and 1500 baud
roughly. On the other hand, crunching with CRU2.DMP[1,REM] occurs at
about 100,000 to 150,000 baud, getting rid of half of the file, for an
effective get-rid-of-disk-constipation rate of 50,000 to 75,000 baud.
Thus to get rid of half of your disk usage, crunching is about 50 times
as fast as datacomputer FTP. I.e. it is 50 times as fast to crunch all
your files to half their size than to purge half of them to datacomputer.
To get completely rid of disk space, it is much faster to crunch
everything, then DFTP the crunched files, than it is to DFTP the original.
Essentially twice as fast, since the crunching time is insignificant compared
to the DFTP time.
I plan to install a datarate (baud) timing routine in CRU2, and later
in CRU3 (SPINDL), so the user can see for himself how much faster than DFTP
and FTP it is. Is anyone other than myself actually using CRU2 ??
I don't see any point in putting the propaganda in the program. As for
how many people use SPINDL, unless there are bugs, don't worry about it.
The availability of SPINDL co-incided with the availability of more
disk so the motivation to use SPINDL was low. However, when the next
disk crunch comes, and it will be soon, the management will resist
increasing the disk quotas of people who don't have good arguments
for not using SPINDL. It wwuld be worthwhile to know how much computer
time in this computer DFTP uses, but I'm not sure you can find out.
∂13-OCT-76 1646 MS
Dear Professor McCarthy,
Could you tell me the file name of your recent draft on
"concept"? I looked at CONCEP[S76,JMC], but it did not look like
the correct one.
Sincerely,
Masahiko Sato
∂13-OCT-76 1859 REM via AMET
All I plan to put into CRU2 and SPINDL (CRU3) is one line telling baud rate, like FTP et al have. Do you really object?
No, I don't actually object.
∂14-OCT-76 0924 QIB Meeting with Bob Calfee
To: REG, JMC
Amy Blue would like to arrange a meeting tomorrow, Friday the 15th at 1:00PM
with Bob Calfee and both of you. Please call her and confirm, X73493.
∂14-OCT-76 1050 JB dinner.
Let us do it Monday at 7 P.M. Address is
103-A, Escondido Village
(Hoskins Court, facing the Fire Station).
Thanks, we'll be there.
∂14-OCT-76 1238 RDR via AMET
To: REG, PROJEC.MSG[LOT,RDR], JMC
We need:
a WHHOIS or FINGER that associates full names and locations with
jobs.
an automatic account opener based oon the reggistrar's tapes
an INQUIRE that will allow people to provide or update reggistrar's local
address information
A BBOARD proggram that will allow people to place one line announcements
in a centrally accessible bulletin board file with pointers to other
files for more information. Entries should remain as long as they
point to an existing file, or until some expiration date.
The system login messages miggght do this function; I have to check.
AID converted from TENEX
TECO likewise
TBASIC ditto
SPSS brpougght up
Dartmouth BASIC library imported
misc. DECUS programs established
DECUS ALGOLW would be a god idea
(that's good up thhere)
a conversational statistics proggram (not planned by the
Statistics consultant--would make some MS student a nice project;
could hunt one up, probably wouldn't be too ggood.)
a CAI proggrram or leson writer like PILOT is desired by Ellen Nold
of te Engineeringg School Writing proggram and several others
(they have it on the 370)
... (and there are many more)
We'll have to establish priorities. You need to fix the terminal a bit more.
∂14-OCT-76 1526 FTP:MRC at MIT-AI (Mark Crispin ) DFTP version 2
Date: 14 OCT 1976 1824-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DFTP version 2
To: REM at MIT-AI, MSC at MIT-AI, AHR at MIT-AI, MACRAK at MIT-AI
To: MAC at MIT-AI, RG at MIT-AI, MRC at MIT-AI, BRONS at MIT-AI
To: DFTP-USERS at MIT-AI, LIS at SU-AI, TVR at SU-AI, JMC at SU-AI
To: LES at SU-AI, REG at SU-AI, JP at SU-AI, JLK at MIT-MC
Message-ID: <[MIT-AI].12426>
CCA has annnounced DFTP version 2, which, unfortunately, does
not have my edits for the SAIL and ITS versions.
This new DFTP will use the terabit memory and has nice hacks
such as wildcarding, etc., and also will soon replace DFTP
version 1. Hopefully, the service will be much better and a
general improvement, but in the next few months expect some minor
hassles.
I created this mailing list to keep you all informed about developments
as they happen; hopefully the only changes you will see are changes
for the better.
I hope to have the ITS and SAIL new DFTP up in a couple
of weeks; it depends on what happens with my time, since I am still
(theoretically) a full-time student...
Mark
How about 4:30 in conference room, and why don't you tell Richard, etc.
∂14-OCT-76 1537 MS SEMINAR NOTICE
Knowledge seminar will be held in small conference room
from 4:30.
∂14-OCT-76 1607 100 : Queenie 1976-77 Faculty/Staff Directory
To: REG, JMC
The thought has occurred to me that the Faculty/Staff Directory is now in the
process of being updated by the University. If LOTS is to be listed in it -
we'll have to do something about telling the right people in the next day or
so. I have the name of a person in Personnel handling this that we could
call. If we don't get in now, we won't be able to until next Fall.
Please make sure Ralph and David get in at 7-3214 and I have Director of
LOTS added to my phone book identification but with 7-4430. Remove
Ralph from 7-1360.
∂14-OCT-76 1404 JMC
CC: RDR, REG
We'll have to establish priorities. You need to fix the terminal a bit more.
[That was in response to a question on what all the random student
volunteers who are poppingg up could do. Partly, their task needs to appeal to them.
I still have to clean the key contacts with alcohol or tuner
cleaner. (I only tweaked them before--I am observing the decay in
servicibility. I spoke with a friend from UC Berkeley and
asked him to chheck on the EECS departments ADM-3's. The response was that
thhey too hhave had the bounce problem, and they advise frequent cleaning,
occasional key replacement, and no hard ponding on the keyboard. My hunt
and peck is extremely ligght typing so I doubt misuse is the problem here.]
hmm, we'll have a problem with student use then.
∂14-OCT-76 1923 RDR via AMET LOTS location
To: LOTS.DIS[P,DOC]:;
It now looks to be a real possibility that LOTS might relocate to the
SCRDT (Stanford center for Research and Development in Teaching) building--
you know, the one whose air conditioningg squeels at Stern Hall. This is not at all definite yet, but is being
seriously studied. This first came up last Monday when in the search for
a machine room to set the 20 up in on an interim basis pending $75,000
readying of Cedar, it was officially observed that a more than adequate and
unused room was located in SCRDT. there is also room for staff and terminals,
provision of 24 hour access, and a much better location.
∂14-OCT-76 1931 RDR via AMET $$
To: JMC, REG, RDR
If we are in SCRDT, six 4-wire leased lines would be needed
to connect to the TRAN--at $40 installation and $5/mo. each.
Six weeks notice is advisable for the phone people.
∂14-OCT-76 1944 RDR via AMET
Who was the Earth Sciences professor on the LOTs Advisory board?
I forget. Irwin Remson was to be, but I don't think that was he.
Please ask Adams without letting him know I forgot and let me know.
∂14-OCT-76 1935 RDR via AMET update
To: LOTS.DIS[P,DOC]:;
LSI terminal kits have arrived (last Friday) and are being assembled.
We have very limited 20 documentation available for inspection and
loan(VERY short term) at Cedar Hall. I will put copies on reserve in Meyer Library if possible.
Arrangements are being made to reproduce some of it.
Also please put some in Computer Science Library.
∂14-OCT-76 1953 RDR via AMET PROJEC.DIS[LOT,RDR]
To: PROJEC.DIS[LOT,RDR]:;
This distribution is for suggestions of the various projects
LOTS volunteers and even staff might undertake. Please give coonsideration
to the matter. The file PROJEC.MSG[LOT,RDR] receives all
messages sent to the PROJEC distribution. I believe the use of this
distribution will become less necessary once we are underway and more
nearly in constant communication. This is separate from the general LOTS
distribution because I would hope for a large volume of
ideas on the matter,
toolarge to hit @LOTS with.
∂14-OCT-76 1938 JMC
hmm, we'll have a problem with student use then.
++ But we can afford the TRAN lines (leased lines there for...), right? ++
∂14-OCT-76 2140 RDR via AMET SIGUCC meeting
Will you be the only speaker relative to LOTS style operation? HHow can you
detail free access computingg when we won't have gotten off the ground
yet?
Indeed! If I go it will be to get ideas.
∂14-OCT-76 2141 RDR via AMET Academic Council (?) mailingg list
To: JMC, REG
What about the idea of sending blurb to Deans, Dept. Heads, et al.? Did that
fall thhrough?
Separately, but to the point now, as mentioned at the Advisory Board
meeting, I will ask Amy Blue about an Acadmeic Council mailing list to
send something alongg the lines of the questionnaire of long ago
and ggeneral information.
∂14-OCT-76 2223 RDR via AMET
To: PROJEC.DIS[LOT,RDR]:;
HP 2100 downloader/cross assembler plus some hardware (w/CS & EE) so that
CS 111 and EE 181 can use text editor to prepare their three programs/quarter
rather tthan punchingg cards and obtainingg listinggs on SCIP's machhine
way over in Pine Hall.
a "student compiler" for Fortran--first verifying that it is an improvement
over FORTRAN-10.
a TVEDIT for use on SCIP's Tektronix 4023's via the LOTS TRAN lines
(as REG said) a line editor for use by the LSI's
a sscheduling system to deterrmine whhen the TA's for a particluar
course were around or due to be around.
modify the LPT spooler to not print 6-8 extra pagges of "Identification"
with each listing. It could probably get by with a singgle
suitably distinct line at the top of the first page of the listing.
Many listings will be of only one page. UC Irvine's Sigma 7
does listings ordered from a terrminal with this little amount
of Identification.
an encrypter for rendering data private
a "SEND command for the monitor/exec
gripe facility
∂14-OCT-76 2307 JMC
Indeed! If I go it will be to get ideas.
[Well, hhave you seen the mention of it in the latest SCIP Bulletin? It
sounds like Stanford is running the show or something, evn if it is
not in California.]
∂15-OCT-76 1058 RDR
To: REG, JMC
hedber.msg
∂15-OCT-76 1100 JMC*
monbec and nation.xgp
∂15-OCT-76 1100 RDR
To: REG, JMC
∂15-OCT-76 0928 FTP:HEDBERG at SUMEX-AIM projec.<??>
Date: 15 OCT 1976 0928-PDT
From: HEDBERG at SUMEX-AIM
Subject: projec.<??>
To: rdr at SAIL
David,
Many of the projects listed there (in that message) are available
at SUMEX ... I am having a meeting today with Tom R. and I'll see
what his feelings are toward software flow from SUMEX. All the
stuff written here was paid for by a government grant, so should
be available to educational instutitions for free. -Erik
-------
∂15-OCT-76 1502 100 : QIB
Joe Wegstein stopped by to see you.
∂15-OCT-76 1920 RDR
To: LOTS.DIS[P,DOC]:;
SCRDT
It has been arrived at that LOTS will live in SCRDT. Besides the
machine, there is a room of about 700 square feet which will
house about 15 terminals and a few desks. (This is room 105.)
The rest of the terminals and more desks will be located in an
as yet unfinalized place--perhhaps in a room
somewhere on the Quad or at Meyer Library.
∂15-OCT-76 1921 RDR via AMET 303
To: JMC, REG
It justt occurred to me that once the proximity of Meyer Library is lost,
there is not so much advantage of 303 over Cedar Hall!!! TThose in
contact with the machine and thherefore working in SCRDT will be
little likely to stroll over to 303 very often. Students living on thhe
Stern Hall side of campus would not like to ggo on to 303 if there are
terminals in SCRDT, and those in Roble and Laggunita are closer to Cedar.
The walk from SCRDT to 303 is longer thhan that from Pine to Cedar.
Wherever we locate, we will NEED storage, and preferably
a separate room for any printer.
Once the TTerman Enggineering Center is
done, that is the ideal supplement to Cedar (besides the obvious dormitory
and fraternity locations). At that point (this summer) we could move in from
Cedar and eventually over to any permanent home in 303, after renovation
takes place. There would be no displacing of anyone during the two Winter
and Springg Quarters. The laying of cable between SCRDT and Cedar/Pine
(Jordan Quad) is good for any eventual tie-in with the SCIP TRAN as well
as being able to catch 303 and Terman on the wayy, and would cover our
inittial six TRAN lines. We can give up part of Cedar as a sop to
Provostial reasoning. This really seems pretty good to me; the splitting
of administrative capacity is no ggreater between Cedar and SCRDT than between
303 and SCRDT--neitther one is even in site of each other. Of course,
Meyer Library is quite another matter from 303. It is possible that
a Cedar or 303 location could be shut down at night, reduciing the Securityy
problems caused by splitting locations.
∂16-OCT-76 1732 LSP LISP
The current versions of the various and sundry 206-related files are now
on the area [206,LSP]. This area has apparently been in existence for
some time, so there is no need to worry about granting it official status.
∂16-OCT-76 1859 DCL
JOHN-HOWS MY ADJUNCT PROF. CASE PROGRESSING?-DAVID
∂16-OCT-76 2332 RDR via AMET Computer Group meeting
To: LOTS.DIS[P,DOC]:;
We will discuss LOTS, orgganize, and show a film on timesharing (comedy film).
7:30pm Wednesday next (20 October 1976) Roble Hall Main Lounge.
∂16-OCT-76 2350 RDR via AMET New network port for the ISI DECsystem-20
To: JAB, SAU, MXB, PLH, DSB, REG, JMC, hedberg @ SUMEX-AIM, GFF, DLB
To: MRB
It is now site 116 decimal (@o 116 from tips).
The mnemonic ISIE is about to be installed in the SAIL
hhost table (tn ISIE).
∂17-OCT-76 1309 FTP:FEINLER at OFFICE-1 Re: Stanford network addresses
Date: 17 OCT 1976 1311-PDT
From: FEINLER at OFFICE-1
Subject: Re: Stanford network addresses
To: JMC at SU-AI
cc: FEINLER, rubin at SU-AI
In response to your message sent 16 OCT 1976 1713-PDT
Dear John,
I am not sure why I received the message you sent regarding
use of last names in mailbox addresses. I am guessing that you
are saying you prefer the full last name over initials. If that
is true, I will be glad to change to last names if the Liaison
(currently Jeff Rubin) will supply me with a list of name changes.
I do not choose what mailbox addresses go into the Directory.
I merely put what the Liaison or individual tells me he wants
and some of the people at SAIL are rather adamant about wanting
initials. Personally, I happen to agree with you that the last
name is more meaningful and one is apt to remember it before
remembering someone's initials. (As a matter of fact we use initials
here at ARC and I sometimes 'blank' on remembering the initials
of people I know perfectly well by name.) Let me know if you
would like to have SAIL people's network addresses changed to last
names.
Regards,
Jake
-------
∂17-OCT-76 2149 RDR via AMET storage
To: JMC, REG
We need storage somewhere too, and Cedar looks to be the only place at present.
By the way, available for our use in Terman will be one large room with two
smaller ones (10 x 12) adjoining, these all having false floor, and a room
down the hall and around the corner suitable for offices and about the size
of the large room, the size of which escapes me. Terman's location is also
excellent.
∂18-OCT-76 1057 PAW
∂14-OCT-76 0955 FTP:TAYNAI at SUMEX-AIM Vita for EAF
Date: 14 OCT 1976 0954-PDT
From: TAYNAI at SUMEX-AIM
Subject: Vita for EAF
To: PAW at SU-AI
cc: Taynai, Feigenbaum
EDWARD A.FEIGENBAUM October 14, 1976
Computer Science Department
Stanford University
Stanford, California
Age: 40
EDUCATION
Ph.D., Doctoral program in the Behavioral Sciences, Graduate School
of Industrial Administration, Carnegie Institute of Technology,
Pittsburgh, Pennsylvania, September, 1959.
B.S., Electrical Engineering, Carnegie Institute of Technology, 1956.
EXPERIENCE
Stanford University, Stanford, California
Chairman, Computer Science Department, 1976 -
Professor of Computer Science, 1969-
Associate Professor of Computer Science, 1965-68
Director, Stanford Computation Center, 1965-68
University of California, Berkeley
Associate Professor, School of Business Administration, 1964
Assistant Professor, School of Business Administration, 1960-63
Research Appointment, Center for Human Learning, 1961-64
Research Appointment, Center for Research in Management Science,
1960-64
Editor, Computer Science Series, McGraw-Hill Book Company, New York,
1965-
Member, Computer and Biomathematical Sciences Study Section, National
Institutes of Health, Bethesda, Md., 1968-72.
PROFESSIONAL SOCIETIES
American Psychological Association, American Association for the
Advancement of Science, Association for Computing Machinery (member
of National Council of ACM, 1966-68)
BOOKS AND MONOGRAPHS
Computers and Thought, co-editor with Julian Feldman, McGraw-Hill,
1963.
Information Processing Language V Manual, Englewood Cliffs, N.J.,
Prentice-Hall, 1961 (with A. Newell, F. Tonge, G. Mealy, et.al.).
An Information Processing Theory of Verbal Learning, Santa Monica,
The RAND Corporation Paper P-1817, October 1959 (Monograph).
PAPERS, 1965-72
This list is organized by topic.
Heuristic DENDRAL Project
(1) J. Lederberg and E. A. Feigenbaum, "Mechanization of Inductive
Inference in Organic Chemistry", in B. Kleinmuntz (ed), Formal
Representations for Human Judgment, (Wiley, 1968). (Also Stanford
Artificial Intelligence Project Memo No. 54, August 1967).
(2) E. A. Feigenbaum and B. G. Buchanan, "Heuristic DENDRAL: A
Program for Generating Explanatory Hypotheses in Organic Chemistry",
in Proceedings, Hawaii International Conference on System Sciences,
B. K. Kinariwala and F. F. Kuo (eds), University of Hawaii Press, 1968.
(3) B. G. Buchanan, G. L. Sutherland, and E. A. Feigenbaum, "Heuristic
DENDRAL: A Program for Generating Explanatory Hypotheses in Organic
Chemistry". In Machine Intelligence 4 (B. Meltzer and D. Michie, eds)
Edinburgh University Press (1969). (Also Stanford Artificial
Intelligence Project Memo No. 62, July 1968.)
(4) E. A. Feigenbaum, "Artificial Intelligence: Themes in the
Second Decade". In Final Supplement to Proceedings of the IFIP 68
International Congress, Edinburgh, August 1968. (Also Stanford
Artificial Intelligence Project Memo No. 67, August 1968.)
(5) J. Lederberg, G. L. Sutherland, B. G. Buchanan, E. A. Feigenbaum,
A. V. Robertson, A. M. Duffield, and C. Djerassi, "Applications of
Artificial Intelligence for Chemical Inference I. The Number of
Possible Organic Compounds: Acyclic Structures Containing C, H, O
and N". Journal of the American Chemical Society, 91:11 (May 21,
1969).
(6) A. M. Duffield, A. V. Robertson, C. Djerassi, B. G. Buchanan,
G. L. Sutherland, E. A. Feigenbaum, and J. Lederberg, "Applications
of Artificial Intelligence for Chemical Inference II. Interpretation
of Low Resolution Mass Spectra of Ketones". Journal of the American
Chemical Society, 91:11 (May 21, 1969).
(7) B. G. Buchanan, G. L. Sutherland, E. A. Feigenbaum, "Toward an
Understanding of Information Processes of Scientific Inference in
the Context of Organic Chemistry", in Machine Intelligence 5,
(B. Meltzer and D. Michie, eds) Edinburgh University Press (1970).
(Also Stanford Artificial Intelligence Project Memo No. 99, September
1969.)
(8) J. Lederberg, G. L. Sutherland, B. G. Buchanan, and E. A.
Feigenbaum, "A Heuristic Program for Solving a Scientific Inference
Problem: Summary of Motivation and Implementation", Stanford
Artificial Intelligence Project Memo No. 104, November, 1969.
(9) G. Schroll, A. M. Duffield, C. Djerassi, B. G. Buchanan, G. L.
Sutherland, E. A. Feigenbaum, and J. Lederberg, "Applications of
Artificial Intelligence for Chemical Inference III. Aliphatic Ethers
Diagnosed by Their Low Resolution Mass Spectra and NMR Data".
Journal of the American Chemical Society, 91:26 (December 17, 1969).
(10) A. Buchs, A. M. Duffield, G. Schroll, C. Djerassi, A. B. Delfino,
B. G. Buchanan, G. L. Sutherland, E. A. Feigenbaum, and J. Lederberg,
"Applications of Artificial Intelligence for Chemical Inference IV.
Saturated Amines Diagnosed by Their Low Resolution Mass Spectra and
Nuclear Magnetic Resonance Spectra", Journal of the American Chemical
Society, 92 (1970), 6831.
(11) Y. M. Sheikh, A. Buchs, A. B. Delfino, G. Schroll, A. M. Duffield,
C. Djerassi, B. G. Buchanan, G. L. Sutherland, E. A. Feigenbaum and
J. Lederberg, "Applications of Artificial Intelligence for Chemical
Inference V. An Approach to the Computer Generation of Cyclic
Structures. Differentiation Between All the Possible Isomeric
Ketones of Composition C6H100", Organic Mass Spectrometry, 4 (1970),
493.
(12) A. Buchs, A. B. Delfino, A. M. Duffield, C. Djerassi,
B. G. Buchanan, E. A. Feigenbaum and J. Lederberg, "Applications of
Artificial Intelligence for Chemical Inference VI. Approach to a
General Method of Interpreting Low Resolution Mass Spectra with a
Computer", Chem. Acta Helvetica, 53 (1970), 1394.
(13) E. A. Feigenbaum, B. G. Buchanan, and J. Lederberg, "On Generality
and Problem Solving: A Case Study Using the DENDRAL Program". In
Machine Intelligence 6 (B. Meltzer and D. Michie, eds.) Edinburgh
University Press (1971). (Also Stanford Artificial Intelligence
Project Memo No. 131.)
(14) A. Buchs, A. B. Delfino, C. Djerassi, A. M. Duffield,
B. G. Buchanan, E. A. Feigenbaum, J. Lederberg, G. Schroll, and
G. L. Sutherland, "The Application of Artificial Intelligence in the
Interpretation of Low-Resolution Mass Spectra", Advances in Mass
Spectrometry, 5, 314.
(15) B. G. Buchanan, E. A. Feigenbaum, and J. Lederberg, "A Heuristic
Programming Study of Theory Formation in Science." In proceedings of
the Second International Joint Conference on Artificial Intelligence,
Imperial College, London (September, 1971). (Also Stanford Artificial
Intelligence Project Memo No. 145.)
(16) D. H. Smith, B. G. Buchanan, R. S. Engelmore, A. M. Duffield,
A. Yeo, E. A. Feigenbaum, J. Lederberg, and C. Djerassi, "Applications
of Artificial Intelligence for Chemical Inference VIII. An Approach
to the Computer Interpretation of the High Resolution Mass Spectra of
Complex Molecules. Structure Elucidation of Estrogenic Steroids",
Journal of the American Chemical Society, 94 (1972), 5962-5971.
(17) B. G. Buchanan, E. A. Feigenbaum, and N. S. Sridharan, "Heuristic
Theory Formation: Data Interpretation and Rule Formation". In
Machine Intelligence 7, Edinburgh University Press (1973).
Information Processing Model Building in Psychology
(1) "Information Processing" in Readiness to Remember: Proceedings
of the Third Conference on Remembering, Learning, and Forgetting,
Gordon and Breach (1972).
(2) "Information Processing and Memory," Proceedings of the Fifth
Berkeley Symposium on Mathematical Statistics and Probability,
Volume 4 (Biology and Health), University of California Press, 1967.
Reprinted in Norman, D. (ed.) Models for Memory, Academic Press (1971).
IFIP Congresses
(1) Invited speech: "Artificial Intelligence: Themes in the Second
Decade." In Final Supplement to Proceedings of the IFIP 68 Congress,
Edinburgh, August, 1968. Also available as A.I. Project Working Paper
No. 67, August 1968.
(2) Report on Panel on the Mechanization of Creative Processes. In
Kalenich, W. (ed.), Proceedings of IFIP Congress 65, Volume 2, Spartan
Books, 1966, pp. 600-601.
Stanford Computation Center
"Computers at Stanford," (with N. Nielsen). In Stanford Annual
Financial Report Summary, Stanford University, November 1967.
Reprinted in IBM Computing Report, Vol. IV, No. 3 (May, 1968), 15-18.
Other
"Soviet Computer Science, Revisited." Proceedings of the 20th ACM
National Conference, August, 1965, pp. 225-226.
Papers, Pre-1965:
(1) "Memory Mechanisms and EPAM Theory: Monologue and Interchange
at the First Conference on Remembering, Learning and Forgetting,"
published in Kimble, D. (ed.), The Anatomy of Memory, Science and
Behavior Books, Palo Alto, 1965.
(2) "Studies in Information Processing Theory: Similarity and
Familiarity in Verbal Learning," The RAND Corp. RM-3979, Santa
Monica, Calif., February, 1964. Also appeared as, "An Information-
Processing Theory of Some Effects of Similarity, Familiarization, and
Meaningfulness in Verbal Behavior, Vol. 3, No. 5 (October 1964)(with
H. A. Simon).
(3) "Computer Simulation of Human Behavior," in Proceedings of the
1963 Midwest Human Factors Society Symposium on Human Factors and
Computers.
(4) "Experiments with the EPAM Simulation of Verbal Learning," in
Symposium on Simulation Models: Methodology and Applications to the
Behavioral Sciences. (A. Hoggatt and F. E. Balderston, eds.),
South-Western Publishing Company, Cincinnati, Ohio, 1963 (with
H. A. Simon).
(5) "Brief Notes on the EPAM Theory of Verbal Learning," Verbal
Behavior and Learning--Problems and Processes, McGraw-Hill, (Cofer
and Musgrave, eds.) (with H. A. Simon).
(6) "Artificial Intelligence," 1960-1962 Report to the 1963 Congress
of the International Scientific Radio Union. Also in IRE Transactions
on Information Theory, October 1963.
(7) "A Theory of the Serial Position Effect," British Journal of
Psychology, 53 (August 1962), 307-320 (with H. A. Simon).
(8) "An Experimental Course in Simulation of Cognitive Processes,"
Behavioral Science, 7 (April 1962).
(9) "Generalization of an Elementary Perceiving and Memorizing
Machine," The RAND Corp. Paper P-2555, March 1962. Also in Proceedings
of the Second International Congress on Information Processing,
Munich, Germany, 1962 (with H. A. Simon).
(10) "Soviet Cybernetics and Computer Science, 1960," Communications
of the Association for Computing Machinery, December 1961. Also in
Transactions of the IRE Professional Group on Electronic Computers,
December 1961.
(11) "Forgetting in an Association Memory," Preprints of the 1961
National Conference of the Association for Computing Machinery, 15
(September 1961) (with H. A. Simon).
(12) "The Distinctiveness of Stimuli," Psychological Review, 68
(July 1961), 285-288 (with H. A. Simon).
(13) "Performance of a Reading Task by an Elementary Perceiver and
Memorizer," The RAND Corp. Paper P-2358, July 1961. Also in
Behavioral Science, January 1963 (with H. A. Simon).
(14) "The Simulation of Verbal Learning Behavior," Proceedings of
the 1961 Western Joint Computer Conference, 19 (May 1961), 191-229.
(15) "Latent Motives, Group Discussion and the 'Quality' of Group
Decisions in a Nonobjective Decision Problem," Sociometry, 23 (March
1960), 50-57 (with J. March).
(16) "Models in a Behavioral Theory of the Firm," Behavioral
Science, 72 (April, 1959), 597-599 (with R. Cyert and J. March).
1RESEARCH SUPPORT AND PENDING APPLICATIONS: Edward A. Feigenbaum
1. Agency: Advanced Research Projects Agency
Contract Number: DAHC-15-73-C-0435
Title of Contract: Heuristic Programming Project
Period of Contract: July 1975 to June 1977
Annual Budget Level: $200,000
Fraction of time committed: 40% Academic year; 90% Summer
2. Agency: National Institutes of Health
Grant Number: RR-00612-05A1
Title of Grant: Resource Related Research: Computers and Chemistry
Period of Grant: May 1, 1974, to April 30, 1977
Annual Budget Level: $276,197 (direct costs)
$368,292 (total award)
Fraction of time committed: 10%
3. Agency: National Science Foundation
Grant Number: DCR 74-23461
Title of Grant: Automation of Scientific Inference:
Heuristic Computing Applied to Protein Crystallography
Period of Grant: February 1975 to January 1977+6
Annual Budget Level: $62,825
Fraction of time committed: 20%
There are no pending applications for which Professor Feigenbaum has
committed his time.
-------
∂18-OCT-76 2215 FTP:MRC at MIT-AI (Mark Crispin ) DFTP
Date: 19 OCT 1976 0113-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DFTP
To: REM at MIT-AI, MSC at MIT-AI, AHR at MIT-AI, MACRAK at MIT-AI
To: MAC at MIT-AI, RG at MIT-AI, MRC at MIT-AI, BRONS at MIT-AI
To: DFTP-USERS at MIT-AI, LIS at SU-AI, TVR at SU-AI, JMC at SU-AI
To: LES at SU-AI, REG at SU-AI, JP at SU-AI, JLK at MIT-MC
Message-ID: <[MIT-AI].14043>
CCA has informed me that the changeover from the version 1 to
version 2 Datacomputer will be gradual, so there is no need to
worry about hassles yet. It looks like I will have the new DFTP
at least in an experimental version this weekend if I can get up
to AI and do heavy editing then(barring foul weather and evil
fortune...).
If you're interested in some nifty info on what to expect in the
new DFTP, read the file:
on MIT-AI: MRC;NDFTP CRUFT
on SAIL: NDFTP.CFT[NET,MRC]
∂19-OCT-76 1333 RDR via AMET SCIP TRAN
Base on the extent of use by CS Department people on campus, I'd say tthat
the AI Lab should be on the TRAN. They have allowed the EE department SIGMA
5 to connect one port. The advantagge is a) accessibilty oof the TRAn
via a campus extension (7-0551) and therefore the lack oof message unit
charges from other campus extensions, the SCIP terminal system such as it is,
and good will with SCIP--Dickens would love the idea.
We have been pursuing it.
∂19-OCT-76 1415 RDR via AMET Provost should pay
To: REG, JMC
When I was trying to suggest to Amy Blue today that since otherwise the floor
would need new linoleum, she should at least HELP pay for the carpet out of
the $75,000, she was not at all responsive. Then when I asked who payed for the
carpet at Pine Hall for SCIp, Esparza smiled and looked to Amy. She said
that didn't matter in a way which clearly indicate tthat it came out of Plant
Maintenance; but she didn't want it to for LOOTS. Now it is
from SCIP's rate base that we are trying to offer three times the computing
for the same money, so it is essential thatt we not be held responsible
financially for anything they wouldn't be--including carpet! I also would like
to see cableing across campus (or the labor therefore) come
out of the $75,000! Not only do we need it, but by getting IMSSS' cable
free and efficiently runnuing it, we arre saving the University the
expense caused by the current ridiculous use of telephone lines strung in
University conduitts, but RENTED from tthe phone company. Prinate wires
hould have been run long ago.
Not only that, but in general we are being geenerally accomodating in moving
our designated location at this late date, to save expense, and
considerations to preserve tthe quality of our proggram, AS WE SEE IT,
should be in the front of any planning ggoing on. If we have a cable to
a cluster in CEdar, we could use the existing 19 pair cable between Meyer
and SCRDT to put a cluster of 8-10 terminals
in the one seminar room on thhe corner by the Escondido side exit of Meyer and
visible from SCRDT. The cable would tthen connect SCRDT to the Pine-Cedar
area, going by Terman for future use. The 300 pair in the cable could be put
to use by us, SCIP, IMSSS, and others to save the cosst of 300*$3.00/mo.
from the phone company, not to mention the 300*$40 one shot
installation fee for the first time each pair's phone company alternative
were insttalled!
∂19-OCT-76 1858 JB thesis.
When could we talk about my thesis work?
∂19-OCT-76 2011 RDR Status Report
To: LOTS.DIS[P,DOC]:;
It is now likely that we will be located in SCRDT for the computer
and one cluster of terminals, with a nearby cluster of terminals
on the ground floor of Meyer Library in one seminar room. This depends
on the feasibility of maintaining a third terminal cluster
in Cedar by running a many pair cable to the Jordan Quad. This
is premised heavily on the fortcoming completion of the Terman
Engineering Center, to which the Meyer terminals would be moved
this summer (the cable to Cedar would run via terman.) Also,
we note the usefulness of the cable for connections to SCIP's TRAN
∂19-OCT-76 2122 RDR
To: REG, JMC
we have completely forgot about fire suppresion in the machine room?
∂19-OCT-76 2303 RDR via AMET 3 things
To: REG, JMC
1) We should ask Franklin to hold the space in Terman hhe had initially
caused to be reserved for LOTS. I believe he may have
reduced the LOTS' allocation somewhat because he thought we were covered in
Pine way back when. All thatt is certain now is part oof a tterminal room.
2) It would aid communication between us and Scott D. Daniels ("SD") if
he had an AI lab programmer designation ("SD"). he is doingg
much of the TENEX SAIL maintenance now that Bob Smith has left IMSSS,
and since he is so much more local, it would be useful to be able to communicate
with him as distinggushed from Bob Smith. Also, he could then use the AI
Lab machhine to access ISI's 20, ratheer than a less desirable arrangement
he has now.
3) The SU-AI --> IMSSS linker could use improvement in at leastt
two areas, especially since we would like to use both the SAIL side and the
IMSSS side in connecting SAIL to LOTS. a) It could be made to handle mail
when not in use otherwise (shades of dial net). b) Itts reliabilitty
in file transfers could be increased. To do work on this now requires someone
to work at IMSSS and probably somebody else to work at SAIL. REGG has someone
to work on the SAIL side; I would like to find someone at IMSSS who is
interestted enough to eiither do tthe work or authorize a third party to perform
it, and permit it to be used. Is there any reason to object to hanving
this link handle mail? Has IMSSS (suppes) opposed this in
tthe past?
∂20-OCT-76 0949 REG
∂19-OCT-76 2122 RDR
To: REG, JMC
we have completely forgot about fire suppresion in the machine room?
→→No, that room is alarmed and sprinklered.
∂20-OCT-76 1147 TOB conf
RANN-2
CAD-CAM IV
I took back the Draper Lab report.
Tom⎇
∂20-OCT-76 1304 RDR via AMET Terminals in dorms
To: REG, JMC
There is a story on page 3 of today's daily whhich shows how eager
everyone is for terminals in thhe dorms.
It also would have been a lot of publicity for LOTs.
No one inthe story explained how people would obtain access to
the computer to which the terminals are connected!
∂20-OCT-76 2157 EHF via AMET CABLE RUNNING
To: LOTS.DIS[P,DOC]:;
SINCE THE TERMAINSL ARE GOING TO BE IN CLUSTERS IT MAKES INFINATELY
MORE SENSE TO RUN A SINGLE PEICE OF COAX AND DO SOMETHING LIKE TIME
DIVISION MULTPIPLEXING OF IT. FOR EXAMPLE (AND TO FIRST ORDER)
50 TERMINALS RUNNING AT 9600BAUD WOULD ONLY REQUE A CABLE WITH
ABANDWIDTH OF 500KHZ, WHICH IS VERY CHEAP, ESPECIALLY
OVER THE SHRT DISTANCES WE ARE TALKING ABOUT. DHE ONLY REAL
EXPENSE BEING THAT OF THE MULTIPLEXOR AND DEMULTIPLEXOR., BUT
IT IS PROBABLY WORTH LOOKING INTO ANYWAY.
EHF
(P.S SORRY ABUT THE TYPING BUT THS TERMIANL.....)
You're welcome to look into it, but when we considered a co-ax or
microwave between the AI Lab and Campus, it seemed like the modulation
and demodulation were very expensive.
∂20-OCT-76 2220 RDR via AMET
To: REG, JMC, QIB
When Plant Services went to Salvage to pick up the desks, filing cabinet,
safe, etc. that we had requested, Claspill was looking for 7 items.
Not being able to find a bulletin board which we had requested, the
Plant Services people brought a huge safe which required a forklift
in addition to the smaller one we had requested. It was probably jointly theirs
and Claspill's fault.
∂21-OCT-76 2311 RDR
To: LOTS.DIS[P,DOC]:;
Len Shustek's info file on the LSI ADM-3 terminal is duplicated in ADM3[lot,rdr]
∂22-OCT-76 0847 RDR via AMET cable situation
Something has to be done about this. Itt is complete lunacy to pay
the phone company's premium rates which are based on their
having obtained various rights of way, when the cable is only going
100-6000 feet in Stanford oowned cabling conduits!
SCIP has been derelict in this matter in tthe past. There are hundreds of
leased lines in use by them on campus. When IMSSS has tried too extend the
sane methods tthey have employed in their own domain, tthey have
met with Plant Services opposition to having anyone but the telephone
company use Stanford's ducts.
In particular, now tthat the Terman Center will consolidate all of the terminals
from the various departmentts moving in, cabling should be arranged for
Terman. This will have a serious impact on our budgett if it has
not occurred before we move in.
In general, the Meyer location would have been so goood for
LOTS, that its ggoodness alone would have made a decision, lett alone
the unique points of dissatisfaction concerning 303 such as isolation
from places where there are people late at night and unavailability of
restrooms and drinking water at night and on weekends.
The provost's people just want their easiest out, and although
of course LOTS will still be a success, it is disgusting tto see
us slighted and essentially the people who will be using the tterminals
misttreated to such an extent, after we have been so incredibly
flexible with the Provost's people.
The administrative capacity strain is ggoing to be every bit as visible
in 303 versus SCRDT as it would be in dorm terminals
versus SCRDT; we are reneging in our committment to put
terminals in dorms, while SCIP of all people are doing so.
This will be perceived by the students in th dorms
when SCIP removes the terminals for lack of use.
I just wanted to express my views now that we have taken the left fork in
the road when the signs all indicatte tthe right one. I am
startingg to believe that even if LOTS is a success, it will be
necesssary that a completely studentt-run computer facility develop
in order that the specific needs of the students be met.
∂22-OCT-76 1006 RDR The LOTS advisory board:
To: LOTS.DIS[P,DOC]:;
Prof. James Adams, Industrial Engineering and Mechanical Engineering
(Chairman)
Prof. Gene Franklin, Electrical Engineering
Prof. Joel Ferziger, Mechanical Engineering
Dennis Brown, Computer Science
J.Q.Johnson, Graduate, Political Science
Drew Lanza, Undergraduate/Graduate, Electrical Engineering
Prof. Robert Calfee, Education and Statistics
Ed Frank, Undergraduate, Electrical Engineering
Prof. John Harbaugh, Geology and Applied Earth Sciences
Prof. John McCarthy (ex-officio), Computer Science
next meeting: Tuesday, 26 October, 4:15pm
Serra House conference room
∂22-OCT-76 1635 RDR
To: LOTS.DIS[P,DOC]:;
Now that we are planning to hold back on use of
LOTS for Winter Quarter, it is especially important that
we cultivate a few ttestt courses whhose use of the systtem will aid us
in achieving the expected 99.9% of eventual use by Spring Quarter.
Potential test users include:
a) any and all independent study courses such as CS293, EE199, EE288,
Physics 390, and the like
b) CS140/EE286 (systems programming) they use or would like
to use a variety of languages anyway
--sail would be fine for them
c) If MIX were available (various versions exist), CS144
d) a special CS class in PDP-10 assmbly lannguage
e) CS103--one unit for learning FORTRAN, which we will have
CS106 conversion would require more careful attention than the above, as
its students are by definition novices, and the course
materials do not exist execept for ALGOL W. Also,
their has been in the past less flexibility and variattion
in the way CS105/CS106 has been taught than in the above courses.
CSD is currently planning at least an experimental small section of
CS105 or CS106 for Winter Quarter. If we get in promptly, and all
seems to be well, I would press for larger use. Nothing special has
to be done to make it available for the individual use courses.
CS103 is also a good bet.
∂22-OCT-76 1805 ZM
I am going to Israel on Sunday (for 3 weeks).
Returning on Nov. 17th. Shalom Zohar
Have a good trip.
∂22-OCT-76 1925 RDR via AMET CS105/6
A point: consulting received by 105/6 students from other
non-TA students probably exceeds that received from TA's! Thus a factor
probably no considered in this regard is the lack of CS105/6 alumni and
others to provide this informal consulting.
All the more reason to allow use as soon as possible this quarter for
those interessted enough to begin then.
You should see the huge lines at Pine where people are awaiting keypunches,
cardreaders, and even CS105 TA's. I hope 50 terminals is enough. People
will have to stop their putting the ordeal off to the last minute
madness.
Really, the 105/106 consulting staffing is "woefully inadequate." It
should be sensitive to the due dates of homework. Their should be twice
the number of man hours scheduled. So we can add that to the goals/solutions set/provided
by LOTS.
I am also worried about whether 45 terminals are enough. It is unrealistic
to expect human nature to change and people to do their work well
in advance of the end of the quarter. There will be some very late
hours towards the end of the quarter. This is another reason for
caution about terminals in dorms until we see how hard it is to
handle the courses. Let me remind you that the university has taken
money mainly spent on course computation to set up LOTS. I see the
largest new application to be on-line editing of reports, etc. However,
when this application begins to compete for terminals, disk space,
and compute cycles with the courses, the University will have to
decide whether to put in some more money. I think they'll do it, but
not until there are some users to say they like it.
∂23-OCT-76 2127 REG
The current effort is in BLURB[lot,jmc] and a copy in your office.
I'll be around to repair it Sunday morning, say after 11AM.
Thanks.
∂24-OCT-76 0022 RDR
To: LOTS.DIS[P,DOC]:;
The Provost's office has decided that LOTS will exist in SCRDT
(machine room and another that houses all staff functions and
public terminals) and room 303 near the Engineering Corner of the
Qad.
Frankly, I am worried about the suitability of room 303
for late-night and weekend use. There are no nearby
facilities active at these times. Restroom and water fountain
facilities are unavailable there. the potential for handling
overflow from LOTS space in other rooms during times when they
are vacant is missing. Room 303 as proposed is isloated and
clearly less desirable than SCRDT and hence would be a
second choice and frequently deserted or in use by one or two
persons. Security for these people and terminals would
be poor. There will be no heat on weeekends or at night.
Room 303 is over 1000 feet away from SCRDT.
If we use 303, we need to do something to make it more nearly
equal with SCRDT than appears to be likely. We want the
staff and users to be in free and easy constant contact. Suggestions
are solicited.
∂24-OCT-76 1309 REG
That's 303 in Engineering corner, and I've included it. Also, other
minor changes.
∂24-OCT-76 1415 SAU via AMET Room 303
To: LOTS.DIS[P,DOC]:;
It seems to me that LOTSS is getting screwed with this space thing.
We are ending up with less space than we would have had in Cedar, and
it is less desirable space too! (If that is possible.) SCRDT is a very
nice place, and it's location is far better than Cedar, but 303 is
a very poor location -- boardering on unusable due to the lack of
security and rest rooms. Also we are ending up withh no place for
the student staff. This last is crutial since we are expecting to
need free student labor to keep LOTS low overhead. If the working
conditions are terrible it is going to be hard to get enough students.
(I am going to look in to getting an office for the computer group
from the ASSU but there should be a student staff office in the
vicinity of LOTS; which the ASSU office probably won't be -- and if
it is LOTS will probably get moved again.)
I agree with SAU and will make the point to the authorities.
∂24-OCT-76 1624 REG Budget
To: RDR, JMC, REG
I now have enough information to state that with the current (and projected)
set of people (REG,RDR,MXB,QIB,ELH,JAB), we are within the personnel budget,
exclusive of student assistants, as set forth in the July 16 communication
to Massy. I believe that the costs for construction of the terminals can
be borne by the Startup costs or Student Assistants budget. I'm a little
worried that Startup Costs budget isn't enough, but perhaps there's enough
money elsewhere to cover all expenses.
∂24-OCT-76 1701 REG
I've added a few more things to the Blurb, and reshuffled some of your additions.
∂24-OCT-76 1735 JMC
To: LOTS.DIS[P,DOC]:;
I agree with SAU and will make the point to the authorities.
∂24-OCT-76 2015 RDR via AMET budget
To: REG, JMC
i thought the same budget that purchased the terminals had enouggh
in it to pay the $50 each for assembly. Startup is already going to be
greatly squeezed by all the other things, including tools for assembly
(I'd bet we have spent close to $1000), without taking anothe $2500
for the assmbly labor. Since it would have been $200 more each
if they were purchased already assembled, the economy seems clear
and whoever permits use of budgets should see that to deny use of
the funds for the labor would discourage this economy.
∂24-OCT-76 2036 RDR via AMET why not list the A-board members in BLURB?
To: REG, JMC
I can't help getting the impression that you spend most of your
time thinking up things for others - especially Ralph and me -
to do. You could dispell this impression by mailing me a list
of substantive things you have been doing recently and expect
to do in the next month.
∂25-OCT-76 1442 RWW AI memo containing proofs
I have started working again on the memo containing the proofs of
Lagrange, Wilson, Ramsey, etc. You wanted at the time to include
your proof of the wiseman puzzle. Could you send me the relevent
file names. thanks. RWW
∂25-OCT-76 1552 JB
I have been scanning Rosza Peter's book and Cartwright's thesis. At
the end of Peter's book there is an appendix on the generalization of
recursive function theory to abstract sets of appropriate structure; also
the basic ideas as to how to generalize the various concepts of recursion
to abstract sets are sketched there. I assume this is what you suggested
doing about LISP. Has this been undertaken by anyone before? As for the
connection of Cartwright's thesis with that, I am not yet clear about it.
Unless you think there is some additional information I should get
now, I want to try out Peter's concepts for LISP before taking to you
again.
Fine.
∂25-OCT-76 2129 100 : RWW CONDITIONAL EXPRESSIONS
Wrote code to parse conditional expressions, but not completely debugged.
Will not be here tomorrow, will get back home late, call there after 1
A.M Thurs if you want me. rww
⎇⎇
∂26-OCT-76 0522 GFF via SRI
Be sure to see:
' #548*(computer)/-ap/nyt/at 02:40/on 26 oct 76' about home computing.
∂27-Oct-76 1400 REG
John Borchek wants to rent a terminal. Shall we? How much? Our
budget says they're being amortized at $30/mo.
∂27-Oct-76 1939 BG Syntactic simplification
To: JMC, CG, RWW, REF
The syntactic simplification routines are available in the system dump
file SMPFOL. We did not put syntactic simplification into the system
FOL because some changes were made to some of FOL's printing routines
and those changes have not yet been checked thoroughly. SMPFOL is not
completely flakey because (as I write this) it has checked half of the
correctness proof of the McCarthy-Painter compiler. More checking will
be completed by next week. Bill Glassmire
∂27-Oct-76 1942 RWW IF THEN ELSE
The parsing functions for FOL for "if then else" now work, but it will
be a while before it can usefully be incorporated into FOL. The reason
is that many internal FOL routines need to be changed first. Even
⊃E (modus ponens) will not work correctly because the routines
for checking if two wffs are equal does not yet know about the
new kind of wffs. I hope that will all be done by the middle of
next week. This includes the rules we discussed.
rww
∂27-Oct-76 1945 RCB Thesis
Prof. McCarthy ...
I have read a couple of engineering statistics books and plan
to read parts of a few others ... I would appreciate any additional
suggestions as soon as possible (3 or 4 days) so I can incorporate them
into the current document.
I appreciate your time and effort.
Bob
∂27-Oct-76 2229 BG Syntactic simplification documentation
To: JMC, RWW, REF, CG
Some documentation of SMPFOL's syntactic simplification commands is pages 10-12
of SMP.DOC[DOC,BG].
∂28-Oct-76 1537 HVA Telephone Call from Martin Davis
To: JMC, RWW
Martin called me re his salary checks, and asked that I let you know
that he will be at A.I. Lab on Nov.15th(he's going to UCLA between
now and then).
∂28-Oct-76 2037 RPG NCOMPLR
To: MACLSP.DIS[AID,RPG]:;
Ncomplr now understands E-files. Files which must not be
E-files remain: LISP.INI, *.FAS, anything seen by GRIND. This last
restriction should be removed shortly. Recall that in order to have
MACLISP understand E-files in normal IO, you should use EREAD instead
of UREAD. EREAD has the same specifications as UREAD and has an autoload
property in MACLISP.
-RPG-
∂28-Oct-76 2212 RDR machine & documentation
To: LOTS.DIS[P,DOC]:;
The machine has been on the loading dock for a while according to
rumor and will be shipped by tomorrow according to promise.
There will be a LOTS section in the Bookstore
textbook department. Manual costs should be quite reasonable at
about $1 per 100 pages, and that includes the Bookstores
"on consignment" fee and all other expenses.
∂28-Oct-76 2306 RDR via AMET
To: JMC, JAB
Maurice says the sources arrived today on a tape and that they were
mailed the 25th. They had promised to mail the sources on the same day
the machine was shipped, so maybe the machine was sent then too. The
earlier word on the end of the month promise was told to
Maurice by Ralph.
The SCRDT people told us of air conditioning unreliability (which
indicates we should firmly communicate to Plant Services our
needs in writing explicitly). The room was covered with grit
that says filtration is messed up.
∂29-Oct-76 0325 FTP:MRC at MIT-AI (Mark Crispin ) SAIL DFTP
Date: 29 OCT 1976 0618-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: SAIL DFTP
To: DFTP-USERS at MIT-AI
CC: DFTP-HACKERS at MIT-AI
Message-ID: <[MIT-AI].19323>
Good news! SAIL DFTP is now up and ready to go. The
file dftp.mrc[up,doc] (or, on ITS: .info.;dftp order) contains the
old manual with an introductory buzzwah handwave statement from
on high(ie, CCA) about the new DFTP.
Also, SAIL has its own node on the Datacomputer now, the SU-AI
node.
I shall contact CCA and arrange for SAIL users to be transfered
over to the new terabit memory Datacomputer as soon as practical.
For those who would like to try the new DFTP, run DFTP from
[net,mrc](the one on SYS: is the same old one)...but none of your
directories are there yet, and I can't create any directories on
the new Datacomputer for SAIL, because (as yet?) I do not
know the node's password.
For iTS users; I am going to start work on the ITS DFTP
now and maybe will have it ready in another week, and I DO have
the psw for that node, so once ready, I'll start creating dirs for
everybody here.
Mark
∂29-Oct-76 1101 RPG GRIND
To: MACLSP.DIS[AID,RPG]:;
The MACLISP grinder now understands E-files. Grinding an E format
file will cause the directory to be flushed.
-rpg-
∂29-Oct-76 1824 RPG BIBOPIZATION
To: MACLSP.DIS[AID,RPG]:;
MACLSP is now fully BIBOPized and SAIL housebroken.
MACLSP, NCOMPLR, & SCHEME all run under BIBOP; MACLSP IO routines
understand E-format files. This includes NCOMPLR and the GRINDer.
Don't forget to use EREAD in place of UREAD for all normal disk IO.
(This is the routine that understands E.)
-rpg-
∂29-Oct-76 2140 FTP:MRC at MIT-AI (Mark Crispin ) Good news and bad
Date: 30 OCT 1976 0039-EDT
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: Good news and bad
To: DFTP-HACKERS at MIT-AI, DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].19656>
First the good news,...
Barring flaky network andOr systems, or something happening here,
the ITS version to hack the new DC will be ready this weekend,
and we can start moving stuff over.
The ITS and SAIL users will be separated at this point, since
SAIL now has its own node(the SUAI node). It appears that
there will be too many hassles to leave things the way they are...
As for the bad news:
"Our (MIT-AI's) position is that it is presently not willing
to pay anything[for DC usage]. There is no way that any real money
can be committed without much prior approval by PHW, etc."
What this means is that if CCA does start charging for using the
DC, this service may vanish without notice for ITS people.
What SAIL and individual groups in the ITS community do, of
course, isn't dependent upon AI's actions, but some hassles can
result.
Hopefully CCA will relent on charging since it is a useful
resource on the network, and one that should be continued. Also,
I have enjoyed hacking DFTP quit a bit, and was hoping to
eventually have ITS and SAIL versions of DCSUBR so other programs
to hack the DC would be possible...
Well, what will happen will happen, and we can just cross fingers and
hope for the best!
Mark
∂29-Oct-76 2138 JAB via TYMT terminal
i was wondering about my request to rent a terminal. i told reg
that i would want a coupler also and would pay about 50-65/month
for a term/coupler deal. i also would honor your request to have
it back should the need arise. let me know sooon. thanx
When do you want to rent it? If you don't want to rent it soon
I will take my time, because there is a policy issue involved
in Stanford buying terminals to rent to people. If I had to
give an instant answer, it would have to be no.
What do you intend to use it for. I wouldn't ask, but if I
discuss it with Vice-Provost Massy, it will have to be on the
basis of being the first swallow of a summer, and the question
is what summer?
∂30-Oct-76 0153 LES
Plausible, but as far as I know there is essentially no conflict over
5506. In fact I almost never see it in use.
∂30-Oct-76 0255 LES
Here is a note to think about.
∂29-Oct-76 1010 FTP:CERF at USC-ISI soviet work on robotics
Date: 29 OCT 1976 0952-PDT
From: CERF at USC-ISI
Subject: soviet work on robotics
To: les at SU-AI
cc: cerf
Les,
In a review of soviet literature, i recently came across an
article by S. Adrieyevskiy on 2Research on Robots at Kiev Institute of
Automation" printed in Pravda Ukrainy in Russian 4 July 1976,
p.3.
Rather incredible claims were made for a robot assembling a toy
automobile from parts. The robot has 2 TV eyes, range finder, movable "hands"
so i assume more than one. The claim was the the robot got
a word description of a car and its components but nothing as elaborate
as the instructions Stanford has been using for AL.
"the robot examines them [the parts] for 40 seconds and lays them out in
the order in which he needs them, then with fantastic speed, he
assembles the play automobile on a movable platform. and note -- this
is without specific mathematical programs, but only from a general word
description of the automobile." This sounds like pure BS tome, but do you
or John McCarthy have nay feeling for the state of the Kiev work? Articles like
this can make us look bad.
Vint
-------
Ask Tom Binford to look into it and inquire of Vint where the translation
can be found. I doubt that Pravda Ukrainy can be found here. The
task, complete with movable platform, sounds like what Donald Michie's
group did at Edinburgh with a toy car, etc. Have they copied Freddy
or has the reporter or translator slipped and ascribed to them
work done at Edinburgh. Harry Barrow at SRI might know.
∂30-Oct-76 1241 JAB via TYMT terminal
i would like to have the terminal relatively soon. i don't see this
so much as buying a terminal and renting it to me as renting to me
out of your unused stock. this is why i offered lots the option of
requesting tthe terminal back on short notice.
i plan to use the terminal primarily for the work i will be doing
for the cs dept under dr. golub and for lots when it becomes available.
∂30-Oct-76 1920 RDR terminal rental
To: JMC, REG, JAB
SCIP rents terminals to their users inluding students who can
afford $100-$150/month. It would seem that LOTS would have the
same perrogative. The difference would be that we would be cheaper and
therefore more students could afford the rental. Also, we use students
to construct and maintain the subject rental terminals. This makes
them interesting jobs that pay well. Also, the students we have working
on terminal construction now are 100% interested in LOTS and the goals
of LOTS, which according to BLURB includes home terminals.
Alternatively, SCIP might well be persuaded to use student labor to
maintain rental ADM-3's at a reasonable price. The idea is however
patently atypical for SCIP; witness LOTS' existence. Also, the rest of
SCIP would tend to tear down rather than to reinforce this
terminal rental scheme; whereas with LOTS we would reinforce it and it us.
If administrative incapacity at the present time is argued; then filethis
away for when the capacity exists but I am not here to make the
suggestion.
What do you think about renting JAB a terminal or even lending him one
temporarily.
∂01-Nov-76 0149 FTP:Wiederhold at SUMEX-AIM NSF Proposal
Date: 1 NOV 1976 0148-PST
From: Wiederhold at SUMEX-AIM
Subject: NSF Proposal
To: jmc at SU-AI
following are my notes ragarding options for the proposed
disolay system. I believe it will be neccessary to discuss
total cost and local capabilities in order to firm up
the proposal. Hope this provides an adequate initial input.
00100 Importance of Graphics:
00101
00200 The use of graphics is an important tool in the development
00300 of new algorithms. When used to display data from measurements
00400 or simulation, graphics provide powerful assistance in hypothesis
00500 formation. The use of graphics will also improve communication
00600 between computer scientists and researchers in other areas who
00700 are interested in applying computer science techniques to their
00800 problems.
00900
01000
01100 Optional Purpose:
01200
01300 The communication among members of the department will be
01400 improved by the use of common facilities. A joint bulletin board
01500 can be made available given a small amount of file storage.
01600
01610
01620
01630 Editing Support:
01640
01650 The proposed display processor will support editing for lines of
01660 text within its image. This will enhance response time for these
01670 minimal tasks which take up much of terminal interaction sessions.
01680 Many of the systems used by Stanford faculty are loaded to the
01690 extent that system response to thes tasks is marginal. Minor
01692 saving in usage charges may also ensue.
01700
01800 Communication:
01900
02000 There is large diversity of computer communications at Stanford
02100 due to the variety of projects and available capabilities.
02200 Computer Science faculty uses many of these links, depending
02300 on their research and educational needs.
02500 These facilities are summarized in Appendix app and illustrate the
02600 problem and the choices faced by CSD faculty. Since the needs
02700 of the department transcend a variety of systems and projects,
02800 any department-wide support can only be obtained by
02900 funding oriented to serve department-wide needs.
02910
03000 In order to provide the communication for the terminal messages
03100 collected in the proposed CSD display system, we propose
03200 to obtain a trunk line with a remote multiplexor
03300 for the TRAN communication switching unit.
03400
03500 The reason for this choice is:
03600
03900
04000 The TRAN is now connected to two of the candidate computing
04100 resources for the Computer Science Department (IBM370/168, SIGMA5).
04110 The LOTS system is to become another host on the TRAN.
04200 Connections to the other resources (Stanford AI, SUMEX, IMSS, etc.)
04300 can be accomplished by allocation of terminal ports to the TRAN.
04400 Such allocations do not disable access to the resources
04500 when they are not in use by the proposed CSD display system, since
04600 the TRAN can be accessed via telephone lines and potentially
04700 equally well from TYMNET or TELNET. Since the TRAN provides
04800 circuit-switching rather than packet-switching services, no
04900 additional delay is introduced into the interaction and echo-response
05000 for full-duplex systems. A disadvantage of the TRAN is that its
05100 services are currently limited to 1200 bits/sec or 120 char/sec
05200 per terminal, with an aggregate limitation for one trunk line
05300 of 72K bits/sec, limiting this service speed to 60 terminals
05400 at a time.
05500
05510
05520 app:
05600
05700 Status of Communication Facilities at Stanford:
05800
05900 ARPANET: The ARPANET connects three local computers used by
06000 CSD faculty: STANFORD AI, SUMEX, and Stanford Research Institute.
06100 Excellent two-way communication, file-transfer, and message
06200 forwarding facilities are available.
06300
06400 TELNET: A TELNET interface is available to support development
06500 of inter-campus educational database sharing. Remote users have
06600 only access to the IBM370/168 unless additional incoming interfaces
06700 are installed. Stanford users can access remote Telnet-nodes
06800 through the TRAN terminal network switch. Telnet provides
06900 long distance terminal-use-oriented message switching.
07000
07100 TRAN-Network Switch: Terminals on dial-up lines or direct lines
07200 can access computers connected to the TRAN switch. This unit
07300 provides digital circuit switching at terminal rates. The TRAN
07400 unit has been installed by SCIP and provides access to its
07500 IBM370/168, a DEC-11/40 used for DECNET and BALLOTS support
07600 (see below) and an XDS SIGMA-5 in Electrical Engineering.
07700 The TRAN will also serve the LOTS system. Other connections
07800 (to Stanford AI and SUMEX) have been considered. The TRAN
07900 can have its port-multiplexors located remotely. Currently 4 of its
08000 8 port multiplexors are located remotely, but within the campus
08100 (2 for the 370/168, 1 for the DEC-11/40, and 1 for the SCIP
08200 systems programmers).
08400 Since the TRAN only provides circuit switching, no software is
08500 required to connect terminal lines via the TRAN for any machine
08600 which supports terminal-oriented remote access.
08700
08800 TYMNET: The SUMEX computer is a host system on TYMNET, so
08900 that remote researchers in Medical Applications of Artificial
09000 Intelligence can communicate from many locations to SUMEX only.
09100
09200 ARAMIS: The network for the American Rheumatism Association
09300 Medical Information system. Remote users have access directly to
09400 the host SCIP 370/168, used by ARAMIS, via TYMNET.
09500
09600 IMSS-SUMEX: A local protocol and hard-wired lines connect the
09700 DEC-10's of IMSS and SUMEX to provide moderate rate file transfer
09800 capability.
09900
10000 DECNET: In order to provide access by other computers to the SCIP
10100 370/168, a development program has been started by SCIP. The chosen
10200 protocol is DECNET, for which software is available for most
10300 DEC and some non-DEC machines. DECNET supports packet-switching
10400 for messages and files at a wide variety of data rates, depending
10500 on installed equipment. A DEC-11/40 of SCIP provides an intermediate
10600 node to access the 370/168 via a high bandwidth connection
10700 built at Stanford. DECNET support in the 370/168 is beginning
10800 to be implemented. This DEC-11/40 is also accessible via the TRAN.
10900
11000 BALLOTS: The Stanford Library project maintains its own multi-drop
11100 network to serve character-oriented CRT terminals operating in
11200 full-display image (rather than line-oriented) transfer mode. Access
11300 to the SCIP 370/168, used by the Ballots project is also via the
11400 previously mentioned DEC-11/40.
11500
11600 In addition, there are local terminal access networks associated
11700 with several of the computers on campus:
11800
11900 Stanford-AI (Data-disc video)
12000
12100 Stanford Grad. (HP-2000 with low speed terminals)
12200 Sch. of Business
12300
12400 Stanford SEL (SIGMAS-5 with low speed terminals)
12500
12600 IMSS
12700
12800 SUMEX (Local lines via Telephone Co.
12900 as well as ARPANET and TYMNET)
13000
13100
13200
13300 <<< Figure >>>
13400
13500
13600 Alternative Connections to the TRAN:
13700
13800 - Proposed Interface - Multiple Lines
13900
14000 The remote TRAN port multiplexor is connected by a single high speed
14100 line to the TRAN main unit using a TRAN specified communication
14200 protocol. The data characters are grouped into frames. SYN
14300 characters define the frames and the position within a fram corresponds
14400 to the device address. The CTC TRAN multiplexor distributes
14500 these signals over up to 60 1200 bits/sec lines from a 72K bits/sec
14600 synchronous line. These signals are collecte and placed on the
14700 Unibus from the 60 lines using individual device interface lines
14800 and Unibus addresses. Standard DEC terminal interfaces
14900 multiplex 16 lines each onto the Unibus. Each character is serviced
15000 independently.
15010
15020 - Alternative Interface - Single Line to Display Computer
15030
15040 Since all communication proceeds at the same rate, the synchronous
15140 line from the TRAN could also be run into a synchronous port of
15240 the PDP-11, such as provided by a DP11-DC. Software has to
15250 be used to distribute the data characters, if any, or to reject the
15350 SYN characters from the line. Unfortunately, the automatic stripping
15360 capability of SYN characters in the DP11-DC cannot be used since
15370 then the destination address will be lost. At 15 instructions/character
15380 for transmit and at the maximum rate for the DP11-DC (50,000 bits/sec
15390 or 6250 char/sec) this stripping on receive and insertion on transmit
15400 of SYN characters places a very significant load on the DEC-11 (>20%).
15410
15420 - Alternative Interface - Single Line to Preprocessor
15430
15440 Another alternative would be to place another processor on the
15450 Unibus, which strips non-data and SYN characters, and places data
15460 characters only on the Unibus with their proper device address.
15470 Transmittal would be carried out in a complementary
15480 fashion. Any micro or pair of micros could handle this task,
15490 provided they can manage the Unibus protocol.
16400
16500 Savings would include the majority of the cost of the
16600 CTC TRAN (a modem and possibly a "Port Expander Interfact may be
16700 required instead"), as well as the 4 DZ-11's. A DP11-DC is $1400 (∞.
16800
16900
17000 Budget:
17100
17400 1 CTC TRAN 63 port MUX $8000
17500 includes modem
17600
17700 4 DEC DZ11E 16 line multiplexors @$3400 13800
17800
17900 Trunk line to central TRAN - installation 50
18000 - monthly 10
18100
18200 63 DEC BC03M null modem lines @ $10 (∞ 630
18300
18400
18500 For optional bulletin board:
18600
18700 1 RK05-AA disk drive (to be shared with resident software
18800 support and diagnostic routines) 5100
18900
19000 2 RK05-KA disk cartridges @$150 300
19100
19200
19300
19400 References:
19500
19600 J. H. Moore (SCIP Network and Small Computer Group): "Planning
19700 for Distributed Computing and Networking at Stanford",
19800 <Stanford Center for Information Processing>, Stanford, Aug. 1976.
19900
20000 M. H. Hu: "Position Paper Advocating an All Digital Data
20100 Communication Network at Stanford University", (Proposes
20200 the TRAN unit, was accepted, and is operational),
20300 <Stanford Center for Information Processing>, Stanford, Jan. 1975.
-------
∂01-Nov-76 1020 REG
For temporary purposes, I'd loan a terminal to JAB. Therefore, we'd be
under no obligation to let him have it for some specified minimum period.
I'm thinking that at the moment I have need for 1 terminal and have 20,
but that within a couple of weeks I'll have need for 42 terminals and have
only 30.
ok, do it.
∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
Date: 1 NOV 1976 2316-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: GOOD NEWS ABOUT DATACOMPUTER
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].21052>
WORD FROM CCA:
" DON'T WORRY ABOUT BEING CHARGED. HARVARD FEELS THE SAME
WAY. THERE ARE NO PLANS TO CHARGE FOR AT LEAST TWO YEARS.
ACCOUNTING ROUTINES ARE CURRENTLY BEING PUT INTO THE DATACOMPUTER,
BUT REAL BILLING WILL NOT HAPPEN IN THE FORESEEABLE FUTURE."
CELEBRATE, PARTY, ETC...
∂01-Nov-76 2048 FTP:MRC at MIT-AI (Mark Crispin ) GOOD NEWS ABOUT DATACOMPUTER
Date: 1 NOV 1976 2316-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: GOOD NEWS ABOUT DATACOMPUTER
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].21052>
WORD FROM CCA:
" DON'T WORRY ABOUT BEING CHARGED. HARVARD FEELS THE SAME
WAY. THERE ARE NO PLANS TO CHARGE FOR AT LEAST TWO YEARS.
ACCOUNTING ROUTINES ARE CURRENTLY BEING PUT INTO THE DATACOMPUTER,
BUT REAL BILLING WILL NOT HAPPEN IN THE FORESEEABLE FUTURE."
CELEBRATE, PARTY, ETC...
∂01-Nov-76 2201 RPG BIBOP
To: MACLSP.DIS[AID,RPG]:;
Don't forget, R MACLSP invokes the latest BIBOP version
of MACLISP.
-rpg-
∂01-Nov-76 2312 RDR via AMET jordan quad
To: JMC, REG
i saw massy.le2[lot,reg]. to put 23 terminals way over in th jordan quad
would be bad when the others were over at SCRDt. i understand your
desire to serve the CS department, but this would be carrying things
too far. the advantages of not having 3 geographically distinct
locations are lost by the increased separation of the two you would then
have. To serve the CSD department, you only need a few terminals, which
would besst be located in PINE, where there is 24 hour activity already
and others bessides Cs to serve. Then this location would almost not
even count, and could be trivially handled. Remember the six lines to the
TRAN which CSD can also use, and realize that TA's for 105/6
are going to have to go to SCRDT to be a all
realistic.
The Meyer library location has the advantage of being so close to SCRDT
to not count as a different location--almost like Pine and Polya.
Security in Cedar would be as bad as 303, now that we would not have
EVERYTHING here. Of course, a mere 10 terminals could be closed down
after midnight possibly.
I suspect Shaw wants to use Cedar for the SCIP directorss. If so, any
one of a number of SCIP functions could be moved from Pine to
Cedar and allow us to use Pine for its 24 hour use feature.
∂01-Nov-76 2324 RDR via AMET communication
To: JMC, REG
I just realize that I had told some of the above things yesterday
to JMC but not REG. Hence, I conclude that even though things
were hectic, we need to have better communicaion, a in sitting down to
talk about such matters.
∂02-Nov-76 0102 CG midterm solutions
I have just completed a solution sheet for the midterm. It is in the
file MIDTRM.SOL[206,LSP]. I am pubbing the file now, and will xerox up
40 copies for distribution tomorrow.
∂02-Nov-76 2109 RDR
To: LOTS.DIS[P,DOC]:;
computer group meeting tomorrow wednesday 7:30pm roble hall
∂02-Nov-76 2112 RDR Provost
To: LOTS.DIS[P,DOC]:;
JMC and REG ha d ameeting with the William Massy, Vice provost, today. As I heard it,
he nixed terminal rentals to students, agreed to
LOTS having a room in Cedar for terminal use for this year,
and didn7t comment when questioned about the security problems
with 303 Engineering.
RDR doesn't have that exactly right. Prof. Massy expressed doubts
about terminal rental, but because of time shortage, the question
was continued till next time which will be a meeting with the LOTS
Advisory Board - Nov. 16. In the meantime, it would be worthwhil
to have an indication of the demand at rentals between $55 and $65
per month. The main reason why we are worried about buying more
terminals for rental now is that INTEL and other manufacturers are
coming out with integrated circuits that will do on one chip what
most of that ADM-3 circuit board does. Therefore, Stanford might
be left holding the bag on the rental terminals as soon as a year
from now. The LOTS terminals can be held until amortized even if
better and cheaper are available, but rental terminals may be
unattractive. This is only a worry and not necessarily a decisive
consideration, but a rental price would reflect the worry to some
extent.
The security problem was discussed, but it seems that
Cedar and Eng. 303 are the best we can do. Those most worried
can concentrate their late night activities in SCRDT, but frankly
I think it will only be marginally less worrisome. When the
terminals are heavily used, there will be plenty of people, and
otherwise SCRDT can be used by the worried.
The computer was shipped Friday Oct. 30 by truck; arrival
date depends somewhat on what else is on that truck.
Prof. Massy agreed to the purchase of a Printronix printer
for each terminal room which will make listings easily available.
∂02-Nov-76 2154 JMC
To: LOTS.DIS[P,DOC]:;
RDR doesn't have that exactly right. Prof. Massy expressed doubts
about terminal rental, but because of time shortage, the question
was continued till next time which will be a meeting with the LOTS
Advisory Board - Nov. 16. In the meantime, it would be worthwhil
to have an indication of the demand at rentals between $55 and $65
per month. The main reason why we are worried about buying more
terminals for rental now is that INTEL and other manufacturers are
coming out with integrated circuits that will do on one chip what
most of that ADM-3 circuit board does. Therefore, Stanford might
be left holding the bag on the rental terminals as soon as a year
from now. The LOTS terminals can be held until amortized even if
better and cheaper are available, but rental terminals may be
unattractive. This is only a worry and not necessarily a decisive
consideration, but a rental price would reflect the worry to some
extent.
The security problem was discussed, but it seems that
Cedar and Eng. 303 are the best we can do. Those most worried
can concentrate their late night activities in SCRDT, but frankly
I think it will only be marginally less worrisome. When the
terminals are heavily used, there will be plenty of people, and
otherwise SCRDT can be used by the worried.
The computer was shipped Friday Oct. 30 by truck; arrival
date depends somewhat on what else is on that truck.
Prof. Massy agreed to the purchase of a Printronix printer
for each terminal room which will make listings easily available.
∂03-Nov-76 0037 JAB via TYMT terminal rental
would it be better to make this the responsibility of a student
organization? (a sipb)
It's a question of whether the University will buy terminals for re-rental;
not how to administer it.
∂03-Nov-76 1335 LES
To: JMC, TOB
∂03-Nov-76 0655 FTP:CERF at USC-ISI Re: Soviet work on robotics
Date: 3 NOV 1976 0640-PST
From: CERF at USC-ISI
Subject: Re: Soviet work on robotics
To: LES at SU-AI
cc: CERF
In response to your message sent 1 Nov 1976 1633-PST
les,
I am trying to retrieve the now circulating abstracts.
Yes, it came from RANd and was the latest series I have
seen. I did not keep a very detailed pointer to the vlume
and page number of the citation, but will try to track it down
for you from here.
Vint
-------
∂04-Nov-76 0024 FTP:MOON5 at MIT-MC (David A. Moon )
Date: 4 NOV 1976 0324-EST
Sender: MOON5 at MIT-MC
From: MOON5 at MIT-MC (David A. Moon )
To: JMC at SU-AI
Message-ID: <[MIT-MC].12520>
COULD YOU PLEASE PUT ME (MOON AT MIT-MC) ON THE LOTS.DIS MAILING
LIST? THANKS.
- DAM
[PARDON MY UPPER CASE]
Done.
∂04-Nov-76 1352 RDR via AMET our ENCRYPTED source tape
To: REG, MXB, QIB, JMC, SAU
Erik has a DEC crypt routine (REL file only) which would appear
to be capable of rendering our source tape intelligible. No
wonder it was so hard to read. What jolly jokers the people
at DEC are...
Let's say we couldn't figure it out, here's the tape and
where's our $10K.
∂04-Nov-76 1813 DSB
I am VERY enthusiastic about the idea of getting an XGP or an
equivalent for LOTS. Anything I could do to further this cause?
I am pursuing the idea of getting such a printer - somewhat better -
for Stanford, but not for LOTS's exclusive use. There are several
problems: Stanford won't pay anything for it until it is determined
that LOTS can meet its main goals, i.e computing for courses and
independent student research. Even then, the demand for high
quality printing goes beyond LOTS to paying users, so that would
have higher priority with Stanford. If someone were to give LOTS
such a printer, we would accept it, of course, but we might have
to severely limit the use of PUB and similar programs in order to
serve the computing ccurses and the independent research. We are
authorized to experiment with letting students unused to computers,
e.g. in an English class, use it for reports to see if it proves
popular. Naturally, one expects that students who are already
computer users will prepare reports with LOTS using the Printronix
which is better than the average student's typewriter. LOTS will
get its own XGP, but I am afraid it can't be soon.
Now, as to what you can do to hurry the day. We need an
accurate estimate of the costs of editing and using RUNOFF or PUB.
We know PUB is very expensive and also that it can be made much
faster by recoding it in machine language with better string handling
programs. A better editor, more friendly to the unwashed than SOS,
would also help. Again it must be economical. My main idea about
how to achieve economy is that it should have relatively big
commands and make heavy use of what passes for a line editor in TENEX
if there is such a thing, but this idea may not be correct.
∂05-Nov-76 0105 RDR via AMET terminal renttal
The only reason for having LOTS do this would be an increase in efficiency
and hence a decrease in price as compared to SCIP's
terminal rentals. Any student can currenttly go to SCIP and rent a tterminal.
It will cost him money and perhaps more of a committment to duration
of the rental than LOTS need require.
They have say 500 terminals and say 5 full time
people to haul them in and invoke service contracts when complaints
are received. Student labor is cheaper tthan SCIP's mess,
and SCIP is dawdling about ADM-3 rental because their would
be a drop in demand for their CRT, the Tek 4023, and besides no one
is complaining.
∂05-Nov-76 0138 RDR via AMET XGP
I fear SCIP would handle such a service as they have CalComp
plotting which requires a job to write the plot tape, and then
incurs a $25/hour charge for plotter time. Certainly, the directors
would reason, an XGP should cost $3/page. After all, a typist can
charge $1, and the XGP looks nicer.
I'd rather see itt start at LOTS,
possibly eating coins to pay for the Xerox supplies, and
then spread to the campus at large, maybe requiring
the laser XGP then and not now. SCIP is too likely to seriously
impair success of such a project.
The CalComp plotter they have is genarally
idle.
As for compute time for PUB: MIT has something called TJ6, which is
supposed tto be much faster; I have asked for information.
This would be a real mess at SCIP as their text processing is currently
limited to Wylbur, which has abou the same features as SOS.
There is no one to magically write PUb for the 370.
TThey would hire a few more programmers for the task. it would
costt a fortune beyond the cost of the XGP itself. SCIP would have
the effect of turning the XGP into an expensive phototypsetter.
LOTS isn't a business - by charter, while SCIP is. The University
won't let us go into the terminal business merely to compete with
SCIP. I might prefer to run a competitive computation center,
because I also think I could do better than SCIP, but we can't.
The justification would have to be serving our particular clientele,
but the meeting Wednesday showed no-one but JAB who wanted to rent
a terminal, and he can be treated as a special case. If the desire
to rent terminals appears later, we can consider it concretely at
that time. I have no objection to your trying to drum up interest
among students - but not on our time.
The worry that SCIP would mismanage and overcharge for an
XGP has been mentioned by everyone to whom I have spoken. Once the
ducks are lined up - in both supply and demand, we can dicker with
SCIP about what the charges would be. If we don't like what we hear,
or if we can't get a reasonably definite answer, then we can look for
another solution - but it won't be LOTS alone, because the University
won't buy it for us, and it won't be free. By the way, SCIP running
the XGP wouldn't mean attaching solely to a present SCIP computer and
wouldn't necessarily involve a PUB on a SCIP computer except to serve
SCIP's customers. The minicomputer running the XGP would get files
ready for printing by telephone directly from all its client computers,
and the 168 would just be one of them. The reason for preferring SCIP
is that they already employ people to remove output from printers and
ought to be able to operate one more printer more cheaply than other
installations, especially since it ought to be 24 hours a day. If this
idea proves false, alternatives exist.
Incidentally, the problem of an inexpensive PUB for LOTS exists independently
of whether the printer is a Printronix or an XGP and independently of
whether it is operated by LOTS, SCIP or some co-op. If you could
co-ordinate some students into volunteering, it would be worthwhile.
TJ6 may be similar to RUNOFF; the M.I.T. people seem to have mainly
switched to PUB for their fancier documents.
∂05-Nov-76 2225 RDR via IMSSSS SCIP
I KNOW THATTHEY ARE OPERATIONALLY A BUSINESS; BUT I WAS UNAWARE THAT
THEYWERE OFFICIALLY CONSIDERED AS ONE BY THE UNIVERSITY. ARE YOU SURE?
ARE THEY LIKE REPROGRAPHICS? I DO NOT SEE WHY THE UNIVERSITY PERMITS
SUCH "SERVICE" ORGANIZATIONS TO EXIST, WHEN, FOR EXAMPLE, SEL PUBLICATIONS
OPERATES SO MUCH MORE CHEAPLY THAN REPROGRAPHICS.
They are a cost center in the sense that the University adds up all
the costs of operating it and charges accordingly. I don't know
that Reprographics has a different status.
Some days ago, I asked you what you were doing for LOTS and haven't
received a reply yet.
∂06-Nov-76 1539 REG
I know how IMSSS does their communications: they put in their own cable.
∂07-Nov-76 0511 RDR
You ask what I am doing besides thinking up things for you and Ralph
to do. Well, I do think up things for myself to do. primarily I want to
make LOTS a success in the eyes of the students; and I put this above
everything else in my involvement in the matter.
Once the machine is here and running, this will take a different form than
at present. So I would not like you to hold me or any other student
coordinator of the future responsible for continuing to do what I have
been doing in this peculiar start-up time. I have been doing things
that would be more likely done by the LOTS secretary because we did
not have Queenie, and then she started only part-time and was located
way off in the sticks at AI. Also, until recently I have been involved in
things that would be done by Ralph except he was also up here. then there
are things that will never need to be done again.
I have been responsible for our geting a great deal of the furniture, etc.
we have needed for terminal assembly and general existence in Cedar.
I have been involved with the assmeblers and served as their point
of communication with LOTS, of which they are part. The time I have
spent explaining LOTS to students I have met for one reason or another
or who have dropped by Cedar is in my opinion badly needed and my
responsibility. Plans that I have made and those I have communicated
to you and more often Ralph took time and benefitted by input from
these other students. i have sought to get them to convey their
needs when I saw them being passed by.
I have handled a portion of University forms filling-out and
interdepartmental hogwash.
I have become familiar with a large portion of the 20 documentation.
Right now I am arranging the reproduction of that documentation.
I have been lending copies of the documentation to appropriate
persons(those who cared enough to ask) because they would
otherwise be uninformed.
I have watched what we needed to acquire like a vacuum cleaner and
telephone service and made arrangements for or gotten such things.
You know i have been investigating set-ups at other universities.
I have stuff on this line to put in the LOTS library when
we get it. I thought of the LOTS library.
I have told things you and Ralph didn't want to keep secret but still
hadn't let out. People have to be informed.
I have done useless things like keeping after Plant services until
they waxed and washed the floors in Cedar. I had a whole
list of things they needed to do and was about to get them to do
it.
I have obtained information from DECUS and essentially studied it.
I have arranged for me to be an associate member and given ralph
the form for installation member. This is more stuff for the library.
I looked at what programs SUMEX runs and found stuff that might be of
interest to us. The same is true of IMSSS but the information
flow has been less.
I have asked questions about the running of the Daily so as to
use the pattern for the running of the student part of LOTS.
I arranged for the forklift to get the computer off the truck with
one day's notice and I got Ralph an administrative guide. i found
out we have to announce spring quarter courses given as noncredit
intro's for students by december 15 to have them be in the time schedule.
There are quite a few other such little things and if you want I'll
mail you a list of the junk that pops up each day, but I
do not see the profit in that.
As for the future, I would say I will continue to do what is needed to
see that no student is uneccessarily denied something he needs to use
LOTS, be it documentaion in the bookstore, a piece of
code that has to be there before his class can use the machine,
a safe place to use the terminals, access to the terminal area
as soon as possible, paper for his line priinter listings,
another student to answere questions, or freedom from accusations
that he's wasting the machine's time because someone else wants
to waste it his way.
I plan to write an annual report making recommendations, including one that
the custom be carried forth, for LOTS' activities, therole
of the advisory board, priorities for expansion, and everything else.
∂09-Nov-76 0018 RDR The 20 appears to be here
To: JMC, ELH, MXB
There was a message on Ralph's terminal from 4:56 today when a North American
driver phoned him. I called him and told him.
Plant Services should be made to install the needed electricity tomorrow.
this Esparza dillydallying is absurd.
∂09-Nov-76 1417 PAW todorovich visit
todorovich called and would like to change his appointment with you to
10:30 in the morning as he is going to Berkeley in the afternoon.
patte
OK to change Todorovich appointment.
∂09-Nov-76 1535 RDR via AMET machine is here!!
To: LOTS.DIS[P,DOC]:;
The 20 was delivered today aaround noon. It is missing half its core and
16 tterminal ports, but the rest of it looks OK.
Plant Services will hopefully do the power installation ASAP. The Planning
Office is done with its form-filling-out.
LOTS may now receive US and ID mail at SCRDT Building, Stanford CA 94305.
We are in rooms 128 and 105. Offices will move over their tthis
week or next, as the current tenants permitt. Phones will be
installed on the 16th. The number 497-3214 will remain with additional
lines added in rotary.
The first documentation should be available in the Bookstore tomorrow.
The LOTS section is supposed to be near computer science, on the metal shelfs
along the railing of the balcony.
∂09-Nov-76 2311 PMF
Our machine has only 128K and 32 terminals. I am screaming.
While you're in Boston you might scream too. Ralph Gorin
∂10-Nov-76 1113 CCG Juan Ludlow
Juan's stipend from mexico has been devalued to about $280 per month.
He's doing first rate work for me, and should get into the phd program next
year. I would expect any investment in him to pay off well. Les has found
some money and is favorably inclined. I suggest we pay him $170 per month
to meet minimum wage standards, as he is becoming unproductive by worrying
about supporting himself. His tuition is still being paid by Mexico.
respectfully requested,
Cordell Green
∂10-Nov-76 1351 RPG PROGV Feature
To: MACLSP.DIS[AID,RPG]:;
Here is a little known feature of Maclisp that may be of some
use:
(PROGV <VAR-LIST> <VALUE-LIST> <FORM1> <FORM2> ... <FORMN>)
EVALUATES <FORM1> ... <FORMN> AS A PROGN IN AN ENVIRONMENT
CREATED BY BINDING THE SYMBOLS IN <VAR-LIST> TO THE
RESPECTIVE VALUES IN <VALUE-LIST>. THAT IS, THE FIRST
TWO ARGUMENTS TO PROGV ARE EVALUATED; THE FIRST MUST
PRODUCE A LIST OF SPECIAL VARIABLES, AND THE SECOND
A LIST OF VALUES. THE VARIABLES ARE THEN BOUND TO THE
VALUES. IF TOO FEW VALUES ARE SUPPLIED, THE REST OF
THE VARIABLES ARE BOUND TO NIL. IF TOO MANY VALUES
ARE SUPPLIED, THE EXCESS VALUES ARE IGNORED.
THE BODY OF THE PROGV IS THEN EVALUATED AS A PROGN,
THE VARIABLES UNBOUND TO THEIR OLD VALUES, AND THE
VALUE OF THE LAST FORM IS RETURNED.
EXAMPLE:
(SETQ A 'FOO)
(SETQ B 'BAR)
(PROGV (LIST A B 'B) (LIST B) (LIST A B FOO BAR))
==> (FOO NIL BAR NIL)
∂10-Nov-76 1439 LES Dialnet
Sedelow returned my call and said that the Dialnet proposal has been
received. The review is being handled by Fred Weingarten (phone 202 632-5743)
and we should probably contact him shortly after the first of the year.
∂10-Nov-76 1450 CET via SUMX Bank Account
Ed Feigenbaum told me make a note of the fact that you
and he had a joint bank account at Great Western Savings,
Palo Alto (Hamilton & Bryant )in the amount of a few
hundred dollars for A. P. Yershov of Russia. He also
asked me to remind you of the existence of the account.
Carolyn Taynai
∂10-Nov-76 2129 MRC via RTGT NEW DFTP TO NEW DATACOMPUTER
To: REM, JP, REG, LES, JMC, TVR, LIS
I'VE CREATED NODES FOR ALL OF YOU ON THE NEW DATACOMPUTER, INCLUDING
THE HOST/PASSWORD RESTRICTIONS THAT I REMEMBERED(IE, FOR JP AND LIS).
THE OTHER HAVE NO RESTRICTIONS AT ALL SET ... IF YOU WANT THEM,
DO:
.R NDFTP
[ATTACHING]
*ENABLE
!CHANGE <
[OK]
ADD A NEW PRIVILEGE? Y (JUST TYPE THE "Y", IT WILL TYPE "ES")
AND THEN ANSWER THE OTHER QUESTIONS IT ASKS. IT WILL MORE OR LESS
LEAD YOU BY THE HAND.
TWO THINGS TO NOTE: [1] CHANGING THE PROTECTION STATUS OF YOUR NODE WILL
DELETE THE PREVIOUS STATUS. IF YOU WANT TO HAVE DIFFERENT STATUS
FOR DIFFERENT HOSTS, IT MUST BE DONE WITH THE SAME CHANGE COMMAND.
[2] I STRONGLY ADVISE AGAINST USING ANY USER OR SOCKET RESTRICTIONS
AS SAIL AND ITS PICK RANDOM SOCKETS FOR A USER TO USE, UNLIKE TENEX
OR ITS.
IF YOU HAVE A PASSWORD PROTECTED NODE WITH CONTROL(IE, WRITE AND MODIFY
) PRIVILEGES AND A NON-PROTECTED NODE WITH READ PRIVILEGES, DFTP WILL
AUTOMATICALLY TAKE YOU TO THE READ-ONLY PRIVILEGE LEVEL. YOU MUST
DO: ATTACH <<<SUAI>YOUR-PROGRAMMER-NAME:YOUR-PASSWORD TO GAIN ACCESS
TO THE CONTROL LEVEL. I EXPLAINED IT FULLY TO REM, AND SINCE HE IS
3,000 MILES CLOSER THAN I AM TO YOU, HE COULD DO A BETTER JOB THAN I CAN
IN EXPLAINING ALL THE TRICKS(IT TOOK ME SEVERAL HOURS).
THE NEW DFTP IS A LOT SLOWER, BUT HAS MUCH MORE STORAGE AND SHOULD BE
EASIER TO USE. YOUR FILES ON THE OLD DATACOMPUTER HAVE NOT BEEN COPIED
OVER YET, HOPEFULLY CCA WILL DO SO THIS WEEKEND.
IF YOU HAVE ANY QUESTIONS, SEND THEM TO ME HERE OR IF YOU'RE WORRIED
ABOUT KEEPING A PASSWORD SECRET(SINCE NEITHER MY MAILBOX AT SAIL OR
MIT-AI IS SECURE AND SEVERAL PEOPLE READ MY MIT-AI MAILBOX), SEND
ANY REQUESTS TO MARK%SRI-AI.
ENJOY!
MARK
∂11-Nov-76 0808 JRA
...gee, I think incremental compilation is neat.
∂11-Nov-76 1415 DCO corky's thesis
Have you had a chance to sign Corky Cartwright's thesis form yet?
∂11-Nov-76 1526 RDR
To: LOTS.DIS[P,DOC]:;
power should be installed tthis Friday and next Monday
∂11-Nov-76 1536 MRC via RTGT NDFTP
To: LES, REG, TVR, REM, JMC
NDFTP SHOULD WORK NOW FOR YOU; (N PEOPLE ARE GETTING THIS...) IT
SEEMS IT INTERPRETS NO PRIVILEGE INFORMATION TO MEAN NO ACCESS...
ANYWAY, I PUT UP TUPLES THAT MEAN NO RESTRICTIONS, SO RUNNING
NDFTP SHOULD WIN NOW.
IF IT DOESN'T JUST YELL "THIS OATMEAL IS LUMPY!!" AT ME...
MARK
∂11-Nov-76 1623 RDR via AMET terminals in SCRDT lobby
To: JMC, QIB
CC: REG
Clark Moore told Ralph and me that terminals in tthe lobby were
part of the original understanding. This is justt great because it frees a
lot of congestion in room 105 and allows to get underway with more terminals
sooner. The lobby will also be a nicer place for the users of these terminals
than 105 will be. There are sofas and it is quiet.
∂11-Nov-76 1817 REG
Meeting with Amy Blue and Marvin Herrington. 11/10/76
When we walked around near 303, Amy discovered for herself how inconvenient
the outdoor Womens' rest rooms were. She said she would approach Dean McGee
again, about allow LOTS users access to restrooms in building 300.
Herrington suggested that a ring-down phone be installed that would connect
directly to the police station. He also suggested additional lighting.
Herrington mentioned that terminals have been stolen in the past, and
said that some physical precautions (alarm or chain) should be taken
as a deterrent.
Also, for safety of personnel, trim bushes near door to 303. say clear
4 to 6 feet on each side of the door. substitute low ground cover.
∂12-Nov-76 0903 JBR
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging!
If you don't delete some of your files, the purger will.
Your disk quota is: 1600
Your files occupy 2310
∂12-Nov-76 0956 HVA Texas Instruments Portable Data Terminal
Should be shipped from Stafford, Texas, Mon. 11/15, arriving here on
Wed. ll/l7 or Thurs. 11/18.
∂12-Nov-76 1209 RDR via AMET CMU-20
To: REG, JMC, MXB, ELH, JAB, QIB, SAU, DSB
Apparenttly, they are short half of their 256K also! I suspect a
plot to conceal tthe heat problem associated with the full complement
of memory.
Why not adopt a less paranoid literary style. Perhaps you suspect they
haven't yet solved the heating problem.
∂12-Nov-76 1438 LES Ed Parker account
He already has one (EBP).
Ohlander's thesis.
∂12-Nov-76 2150 JFR Sail manual
You are tied for second place in the "manual errors" contest. Official
list is LIES[DOC,AIL].
∂12-Nov-76 2346 RWW conditionals
Distributative rule almost completely debugged. If I have time will
finish it this week end. else monday morning.
rww
∂13-Nov-76 1014 JBR
You have exceeded your disk quota.
The files listed below have been purged to reduce your disk
area to your quota of 2000
Before purging, your files occupied 2316
BACKUP.TMP[258,JMC]
BACKUP.TMP[F75,JMC]
RELATI.TEM[CUR,JMC]
QQPUB.RPG[F75,JMC]
QQPUB.RPG[SEN,JMC]
QQPUB.RPG[W76,JMC]
QQPUB.RPG[PUB,JMC]
QQPUB.RPG[E76,JMC]
QQPUB.RPG[LOT,JMC]
QQPUB.RPG[LIT,JMC]
QQPUB.RPG[S76,JMC]
QQPUB.RPG[206,JMC]
QQPUB.RPG[F76,JMC]
QQPUB.RPG[LET,JMC]
SIGART.LST[LET,JMC]
ENERGY.LST[LET,JMC]
GTREE.LST[206,JMC]
NEWELL.LST[LET,JMC]
LEADER.LST[LET,JMC]
LIVERM.REL[ESS,JMC]
WISEMA.DMP[F75,JMC]
CRYPT.DMP[ 2,JMC]
CODE.DMP[ 2,JMC]
BBPP.DMP[F76,JMC]
FOO.DMP[F76,JMC]
SOURC2.LAP[ 1,JMC]
REVA.LAP[206,JMC]
INSANE.LAP[206,JMC]
SEARCH.LAP[206,JMC]
INSAN2.LAP[206,JMC]
INSAN3.LAP[206,JMC]
TICTA2.LAP[206,JMC]
TICTA3.LAP[206,JMC]
TIC3D.LAP[206,JMC]
GTREE.LAP[206,JMC]
TICTAC.LAP[206,JMC]
GAME.LAP[206,JMC]
BASIC.LAP[206,JMC]
REPRES.PRO[ 1,JMC]
EPIS[ 1,JMC]
FUNS[ 1,JMC]
P1[ 1,JMC]
PART[ 1,JMC]
PERM[ 1,JMC]
PATH[ 1,JMC]
PATH2[ 1,JMC]
ANTIN[ 1,JMC]
SYLL[ 1,JMC]
MEET[ 1,JMC]
NONDUP[ 1,JMC]
COMPIL[ 1,JMC]
TIMES[ 1,JMC]
TESTA.SAI[ 1,JMC]
TESTB.SAI[ 1,JMC]
TESTC.SAI[ 1,JMC]
TESTD.SAI[ 1,JMC]
DADDA[ 1,JMC]
PROB1[ 1,JMC]
ORDIN[ 1,JMC]
ROTA.SAI[ 1,JMC]
ROTAT.SAI[ 1,JMC]
ROTB.SAI[ 1,JMC]
ROTC.SAI[ 1,JMC]
SEMAA[ 1,JMC]
INTER[ 1,JMC]
SEMAB[ 1,JMC]
CONVER.SAI[ 1,JMC]
RELREP[ 1,JMC]
MC[245,JMC]
FWGC[245,JMC]
PATH[245,JMC]
PATH2[245,JMC]
DEMO[ 1,JMC]
LISPAD[ 1,JMC]
TESTE.SAI[ 1,JMC]
ICOM[ 1,JMC]
TRANS1[ 1,JMC]
SIMUL[ 1,JMC]
COMPU2[ 1,JMC]
SOURC2[ 1,JMC]
SOURCE[ 1,JMC]
PUZZ.SAI[ 1,JMC]
TCLUBA[ 1,JMC]
TCLUB[ 1,JMC]
BOARDS.SAI[ 1,JMC]
NEWDOC[ 1,JMC]
LIB.RLS[206,JMC]
ECHO.FAI[206,JMC]
REFER.ENC[225,JMC]
OUTLIN[206,JMC]
MCCRAC.LET[ 1,JMC]
PATHS.RLS[225,JMC]
SYMFUN.RLS[206,JMC]
PARKER[ 1,JMC]
GRPDAT.RLS[225,JMC]
GRPALG.RLS[225,JMC]
GROPER.RLS[225,JMC]
DIMEN.RLS[225,JMC]
CHAR.RLS[225,JMC]
PERMU2.RLS[206,JMC]
LARRY2[ 1,JMC]
COMPU2.LET[ 1,JMC]
DEG5.IN[225,JMC]
REPRES.RLS[225,JMC]
S4.REP[225,JMC]
DEG6.IN[225,JMC]
SLOMAN.REF[ 1,JMC]
R42.IN[225,JMC]
CKSUM.DAT[ 1,JMC]
PANIC.SOS[225,JMC]
ANNOUN[225,JMC]
PUZZ.SAI[225,JMC]
PUZZA.SAI[225,JMC]
PUZZB.SAI[225,JMC]
ENCYC1.PRO[ESS,JMC]
PUZZE.SAI[225,JMC]
DRIVE.DIR[ AI,JMC]
MINE.DIR[ AI,JMC]
PTCH2.DIR[ AI,JMC]
KNOW2.AI[ESS,JMC]
ARCH.PRO[ESS,JMC]
ARTNA1.ART[ESS,JMC]
STUD[206,JMC]
RECOG.LET[ 1,JMC]
HEADIN[206,JMC]
MEMMTC.QUA[ESS,JMC]
LANG1.AI[ESS,JMC]
MTC71.QUA[ESS,JMC]
S5.QUA[ESS,JMC]
R1301.ART[ESS,JMC]
R1303.ART[ESS,JMC]
KNOW3.AI[ESS,JMC]
N30[ 1,JMC]
QA.PRO[ESS,JMC]
ARTNAT.ART[ESS,JMC]
IMAGE.PSY[ESS,JMC]
NETJO.PRO[ESS,JMC]
SEMAN.AI[ESS,JMC]
FRANK.STA[ESS,JMC]
COMPUT.STA[ESS,JMC]
MTCSYL.QUA[ESS,JMC]
AISY69.QUA[ESS,JMC]
FILEC.FAI[ESS,JMC]
LETTVI.REV[ESS,JMC]
CH4A[206,JMC]
R1300.ART[ESS,JMC]
LCFMEM.MTC[ESS,JMC]
PEARL.NOT[ESS,JMC]
PUZB.SAI[226,JMC]
PUZZ.RLS[226,JMC]
PUZZ.SAI[226,JMC]
TRANS.DOC[226,JMC]
BLISET.COM[226,JMC]
BLISET.PRF[226,JMC]
IMPROV.DOC[226,JMC]
SETRUL.DOC[226,JMC]
PCHECK.M2[226,JMC]
COND.PRF[226,JMC]
BACKSL[ 1,JMC]
SYSTEM.HAC[226,JMC]
SORTS.DOC[226,JMC]
ADD.PRF[226,JMC]
TH1.PRF[226,JMC]
TH1.COM[226,JMC]
PCHECK.M1[226,JMC]
ADD.COM[226,JMC]
NETJO2.PRO[ESS,JMC]
DI[226,JMC]
FALSE.PRF[226,JMC]
SCWORL.AX2[226,JMC]
ONE.PRF[226,JMC]
IPT73.REP[ESS,JMC]
NSFX.7[ESS,JMC]
NSFX.9[ESS,JMC]
NSFX.2[ESS,JMC]
NSFX.6[ESS,JMC]
NSFX.5[ESS,JMC]
NSFX.8[ESS,JMC]
NSFX.3[ESS,JMC]
NSFX.4[ESS,JMC]
HAYES.FRM[ESS,JMC]
NSF2.PRO[ESS,JMC]
ADTEL2.NOT[ESS,JMC]
PLATT.NOT[ESS,JMC]
REPRES.BIB[226,JMC]
ONTO.NOT[226,JMC]
TASK2.MAR[ESS,JMC]
TASK1.MAR[ESS,JMC]
LETTER.HE2[ESS,JMC]
XLET[ESS,JMC]
ZF.AX[ESS,JMC]
FOO73A[ESS,JMC]
FOON.PR1[ESS,JMC]
ROTE.SAI[ 1,JMC]
ROTD.SAI[ 1,JMC]
ROTF.SAI[ 1,JMC]
HENDRI.REF[ESS,JMC]
SWOPSI.RE[ESS,JMC]
HART.ME1[ESS,JMC]
GGGG[ESS,JMC]
PRO[ESS,JMC]
OUT2[206,JMC]
OUTPUT[206,JMC]
SHUFF2.RLS[206,JMC]
SORT.RLS[206,JMC]
SORTIT.RLS[206,JMC]
M29AUG.MES[ESS,JMC]
SYMPOS[ESS,JMC]
CH1.BH2[ESS,JMC]
CH2.1A[206,JMC]
CLOCK.FAI[ESS,JMC]
FONTS[ESS,JMC]
TASKS.206[206,JMC]
SLIDES[ESS,JMC]
CH5[206,JMC]
FACMIN.MEM[ 1,JMC]
TODO[ESS,JMC]
W74.PLN[226,JMC]
CLASS.REG[226,JMC]
GAME.CHK[226,JMC]
FOO1[ESS,JMC]
FOL2.MEM[226,JMC]
FOL1.MEM[226,JMC]
SUPPES.QUE[226,JMC]
WUTHER.QUE[ESS,JMC]
ROY[LET,JMC]
FORDH.LET[LET,JMC]
TOLLES.LET[LET,JMC]
AD.NET[ESS,JMC]
KNUTH.SAI[225,JMC]
NEWRUL.DOC[226,JMC]
RELIG.SIM[ 1,JMC]
COMPUT[ 1,JMC]
TOLLES.LE1[LET,JMC]
TUCKER.LET[LET,JMC]
TUCKER.LE2[LET,JMC]
TCLUB.MEM[ESS,JMC]
PUZZLE[ 1,JMC]
RUSS[ AI,JMC]
CHYLIN.REF[ AI,JMC]
CHYLIN.LE1[ AI,JMC]
GEN1[ AI,JMC]
DRIVE3[ AI,JMC]
MPRO[ AI,JMC]
PUTCH[ AI,JMC]
PUTCH.DIR[ AI,JMC]
DRIVE[ AI,JMC]
AIBIB[ AI,JMC]
MINE[ AI,JMC]
NOTES2[ AI,JMC]
PUTCH3[ AI,JMC]
BOWDEN.LE1[LET,JMC]
SLAMEC.LE2[LET,JMC]
MATCH.RLS[206,JMC]
CHERN.LE2[LET,JMC]
III[206,JMC]
CKSUM.DAT[206,JMC]
SIMP.PRO[206,JMC]
CARTES.RLS[206,JMC]
FUNS.MLS[206,JMC]
BASIC.OLD[206,JMC]
MAY.ME[LET,JMC]
NSFX.10[ESS,JMC]
MB.AI[ESS,JMC]
HENRY[ESS,JMC]
MC.AI[ESS,JMC]
SKLANS.LE1[LET,JMC]
BIRKHO.LE1[LET,JMC]
GAME.OLD[206,JMC]
∂13-Nov-76 1021 REG
With respect to communications, Bert Stubbs is presently building
a $25 202-style modem. I expect to hear his results next week. If it works,
we can build them and lease lines from Telco. Somewhat more expensive
than the differential driver/receiver protocol, but more general.
∂13-Nov-76 1755 LES Puritanism
While you are in a mood to purify the system and stamp out activities that
are not work related, I suggest that you delete the following:
SWR
GO (Ryder's)
CHECKE (ALS checkers program)
DCHESS
GREEN (old Greenblatt chess program)
TECH2 (another chess program)
HOT
[-NS-] News service phantom
HOT
NS
∂13-Nov-76 1839 FTP:FEINLER at OFFICE-1 Request for your ideas
Date: 13 NOV 1976 1728-PST
From: FEINLER at OFFICE-1
Subject: Request for your ideas
To: NETWORK-USERS:
cc: feinler
The Naval Electronics Laboratory Center, San Diego, has asked the NIC to
distribute the following message to you and to assist them in gathering
your replies.
---------------
Dear User,
The next generation of an ARPA-like telecommunication network is being
contemplated. To assist in the conceptual design of this new worldwide
modern telecommunications system, we would like to have your opinions,
comments, and criticisms concerning current ARPANET features and
operation, and ideas for the next network design iteration. We are
particularly interested in:
1. USER INTERFACE - Any ideas to improve service, operational
procedures, ease of access, standardization; thoughts regarding
anything that impedes your use of the network, its manipulation,
documentation, and ancillary services offered; reduction of cost for
system use in terms of actual money spent or time and/or experience
required.
2. DESIGN ISSUES - Ideas for expansion, new or improved protocols,
host and terminal interfaces, backbone, network configuration,
accounting system, security features, internet capabilities, new
design parameters, and needed implementations.
3. SERVICES AVAILABLE - What software packages, data bases, special
services, hardware access, network access features are most useful or
should be added in the future.
This is a request for voluntary and informal participation by all
ARPANET users in the design of an advanced ARPANET-like
telecommunications system. Responses will be treated individually and
confidentially. We value your knowledge and experience as a user of the
ARPANET and would like to have your ideas and suggestions.
If you wish to submit a paper that has already been written, send it by
U. S. mail to the address below, send it by network mail to
FUTURE-NET@OFFICE-1 (if short), or send a complete pathname to
FUTURE-NET@OFFICE-1 so that the file can be retrieved via FTP.
It would be appreciated if your reply could be received by 1 Dec l976.
Please send your contributions
by Network Mail to FUTURE-NET@OFFICE-1
or
by U.S. Mail to Elizabeth Feinler
Network Information Center
Stanford Research Institute
Menlo Park, California 94025
-------
∂14-Nov-76 1207 RDR via AMET EDUCOM
When you went to Boston, did it happen to be for EDUCOM? There was a meeting
at MIT last week and I was wondering who represented Stanford now that
there is no Associate Provost for Computing.
No, something quite different.
∂14-Nov-76 1500 RDR
To: LOTS.DIS[P,DOC]:;
LOTS core staff as it stands
Ralph Gorin, Manager
Queenette Baur, Department Secretary (will come on full
time later this month; half-time now)
Maurice Bizzarri, Systems programmer
David Roode, student coordinator, half-time
Erik Hedberg, Systems programmer, half-time
John Borchek, Systems programmer and numerical analysis,
lesss than half time
Bob Bell, Statistics consultant, half-time R.A.
Ralph and Queenie come from the AI Lab. John is an R.A. for Prof.
Golub in CS who has experience from Johns Hopkins in LOTS-like
activity. Everyone else is a past or current Stanford student.
Bob is a Sttatistics grad student. Erik is also working
for SUMEX. Maurice has worked for SCIP.
Everyone lasts less than a year except for Ralph, Queenie,
and Maurice. Some volunteers are expected to become core staff types
also, and there will be student part-time employees for
consulting, giving classes, and (initially) guarding SCRDT.
∂14-Nov-76 1507 RDR
To: LOTS.DIS[P,DOC]:;
software
We have ordered the TOPS-20 version of SPSS from the University
of Pittsburgh. Bob Bell has arranged to purchase the
sources for MINITAB. Other software is proceeding as planned.
We could use some SPSS wizards to verify that our version
works right and to organize the documentation.
∂15-Nov-76 1204 PAW
To: FUND.DIS[1,PAW]:;
PLEASE RETURN YOUR UNITED FUND CARD...IT SHOULD BE RETURNED WHETHER YOU ARE
GIVING ANYTHING OR NOT...IF YOU THREW IT AWAY, PLEASE TELL ME SO....THANKX
PATTE
∂15-Nov-76 1523 FTP:JAB at MIT-AI (John A. Borchek )
Date: 15 NOV 1976 1823-EST
Sender: JAB at MIT-AI
From: JAB at MIT-AI (John A. Borchek )
To: jmc at SU-AI
Message-ID: <[MIT-AI].27946>
Would you like to talk sometime about the accounting stuff?
∂15-Nov-76 1619 100 : jab via AMET
When would you like to talk? A campus location would be best for
me. You can call me at 325-9916 (home) or 497-3124 (Serra House)
if you happen to be on campus. I am unable to predict the next time
I can arrange a way to get up the the ai lab though.
∂16-Nov-76 1627 MDD Minimal model of set theory
The sentence:"There exists an ordinal λ such that the class of all sets
constructed before stage λ is a model of ZF" is true in L (the class of
constructible sets), but not in the minimal model.
∂17-Nov-76 0702 JAB via TYMT
To: JMC, LES, EJG, REG, RDR, JAB, geoff at SRI-AI
The file sysdd[act,jab] is a hacked version of the spy. It will complain
to users who are using more than one data disk display during prime time
hours. The complaint will be issued once every 5 minutes. A srccom of this
file with the original spy is in sysdd.dif[act,jab].
∂17-Nov-76 0706 JAB via TYMT discussion
I might be up at the lab Sat. night. If you like we could talk
about the accounting then. If not suggest a time and place and
I will see what I can arrange.
∂17-Nov-76 2052 EJG DD channel spy
To: JBR, JAB, REG, LES
CC: JMC, RDR, geoff at SRI-AI
I have modified JAB's version of the DD channel spy somewhat. I put
in a few more comments, and changed it to complain about multiple DD
channel usage when all DD channels are in use, rather than whenever
it is prime time. It has been tested, but I suggest that JAB be the
one to actually put it up since he is currently working on the new
spy, and so he is essentially in charge of it for now.
Relevant files:
SPY[SYS,EJG] spy source - modified from SPYDD[ACT,JAB]
SPY.REL[SYS,EJG] REL file of above
SPY.DMP[SYS,EJG] DMP file of above
SPY.DIF[SYS,EJG] differences file (compared with original spy)
∂18-Nov-76 1713 EJG DD channel spy
To: JBR, JAB, REG, LES
CC: JMC, RDR, geoff at SRI-AI
The DD channel spy is now in production. A rollback DMP file is
available on [ACT,SYS] in case something goes wrong. At present,
the modified source lives on [SYS,EJG]. If everything goes as it
should, I will replace the source on [ACT,SYS] in a week or two.
Relevant files:
SPY[SYS,EJG] new spy source (presently same as SPY[ACT,JAB])
SPY.DIF[SYS,EJG] differences file (compared with original spy)
ACCT.DMP[ACT,SYS] DMP file of above
ACCT.OLD[ACT,SYS] previous DMP file, for rollback
ACCT[ACT,SYS] old spy source, soon to be replaced
∂18-Nov-76 1907 REG
I left Martin Davis' cards and listing in his mailbox. If he wants more,
you have merely to ask.
∂18-Nov-76 2020 RDR via AMET location problem
I have tried to talk to Ralph about this and I do not know what to
do. As you know, I have consistently disapproved of room 303 in favor of
Meyer Library. I did not get direct exposure tto the Provost people's
atttitude in the matter, but I surmise that their preference for
303 wavers as they originally strongly preferred Meyer. Well, with
tthe permission received from SCRDT to place terminals in the lobby
(actually Clark Moore said that this had been part of the plan all along--
indicating bad communication on our part as I kept trying to get someone
to ask officially for this) it turns out that we can place 10 tterminals
in the SCRDT lobby, 12 in room 105, a conservative 5 on staff people's
desks, 6 on the TRAN, 1 to dial-up, and 1 to AI.
This leaves a mere 13 to be placed in 303 and the Jordan Quad.
What I would advocate would be the placing of 5 in Pine (not Cedar) Hall
in the current CSD consulting room, and 8 in Meyer Library , a ground
floor seminar room.
My reasons for prefering this include increased security for people
and equipment, convenience to SCRDT and the undergraduate community
at Meyer Library, increased liklihood of completion of
preparations by 1 January 1977 (Meyer need next to nothing;
303 needs a lot--new floor, communications, lecture chairs
and raised stage area to be removed, electrical installation, political
arrangements for access to in-building restrooms), and also
a cost savings of $10,000 to $20,000 or whatever it is going
to cost to get 303 ready for two quarters. I do not think we really
need the extra space provided in 303 for public area. The lobby
area in SCRDT is moe than adequate when taken with Meyer Library
space near the seminar rooms. What we need that is being overlooked
is arrangements for a shop either via our own
room or access to the SCRDT shop.
Except for setting a precedent of running in-hous wires rather
than using Telco, cabling to 303 will do little in th eway of
a permanent improvement in university policy. Actually,
by following this rule in THE CASE OF ITS EXCEPTION--namely
for a short term period, we will deter the eventual realization
of Stanfor cable to Termna and Pine.
My preference of Pine over Cedar is based on Pine's status as a 24 hour
facility, the existence of the space, the exposure to SCIP users,
convenience to CSD without being blatantly overly favorable to them,
and comments from other prople.
As far as cabling goes, now is the time to push for
the cooperation between us and SCIp and the Provist people
to cable our needs to Terman for the Spring on the
grounds that they are splitting us up and this the
most cost-effective way to deal with it, and for the oter agencies
invloved that their needs are similarly at stake. We could take
advantage of through cabling to Terman and Pine from SCRDT to
tak over the leased lines we lease initially to get to the TRAn
and Pine.
I should mention that I am basing th cost savings partially
on the existence of a Stanford owned 19 pair cable from
SCRDt to Meyer currently existing! This was anounced by Gil Lovelace
at one of the meetings and promptly inored by all
as inadequate and inconsequential therefore. Our
day-to-day operating budget for the first year has been seriuosly
impacted as things stand now by the move from Cedar to
SCRDT and elsewhere. Increasing the numebr of local terminals
in SCRDT saves communications costs, as does being able
to use our cables and avoid line rental ad/or modem costs
with leased lines. Each line to the TRAn and Cedar/Pine
will currently require a $40 installation and $8/mo. leased
line plus requiring us to use modems at hundreds of
dollars per line initial cost to meet tariff requirements.
Of course we may well be able to ignore theses requirements but
we cannot count on it. the result is at least a delay in
implementation of these connections...
I have said these things individually as the situation
evolved; the conclusion is overwhelming tto me when I set it all down
at once. What do you think?
∂18-Nov-76 2057 RDR via AMET NEWS
To: LOTS.DIS[P,DOC]:;
Power was installed this afternoon. There appear to be memory
problems. Also, there was inadequate airconditioning in the machine room
to permit leaving th emachine on.
∂19-Nov-76 1147 TW talking
I was around this morning, but have other stuff
this afternoon. Will you be aroond Monday or Tuesday?
Tuesday afternoon is best for me if you want to seet
a time. I have been doing some revising of the stuff
I gave you, but probably its better to just explain it.
Also do you have anything written on the new stuff you
mentioned? --t
∂19-Nov-76 1843 FTP:MRC at MIT-AI (Mark Crispin ) ITS NDFTP, documentation...
Date: 19 NOV 1976 2142-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: ITS NDFTP, documentation...
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].29650>
ITS NDFTP now works well enough to perform all functions
except for PUT, but wildcards on GET, etc... all work as do
creation dates. This ndftp only exists on AI. Please hold bug
reports until it is completely finished...
WRB@CCA is promising new Datacomputer documentation any
minute now, maybe I'll have it up on SAIL and ITS tommorrow.
Tenative date for full slosh from v.1 datacomputer to v.2
is next weekend....
Hope this info is useful...
Mark
∂22-Nov-76 0001 RDR via AMET 303 location
To: JMC, REG
Since you REG seem to think I'm some out-of-it crackpot
with regard to the 303 location, I wish you'd do one of
a) compare traffic/population at 303 with typical Wilbur/Stern dorm lounge
and Meyer Library at the hours of heaviest student use of computers
(i.e. evenings, nights, and weekends). There is no contest.
b)before you write off Meyer Library without a chance of recovering
it (as you accuse ME of doing with 303) solicit user (i.e. student)
input--NOONE I've talked to would prefer 303 to Meyer!
Finally, in light of the capacity for 30+ trminals in SCRDT the matter is
less unrecoverable and so not such a big deal--I just feel
obligated to try to do everything right. The University wastes
plenty of money and so LOTS can waste some too and when terminals
are put in dorms or Terman, all will be well again.
By the way, I had another inquiry from a house (ie student residence)
that wanted a terminal. i told them to go to SCIP. So far that makes,
Whitman, DKE, Roble anD Flo Mo. Also, I happened on a student
wanting to rent a terminal, making two besides Borchek with no real effort
on anyone's part to solicit input. In a few months that information
should be readily forthcoming.
∂22-Nov-76 1029 RWW FOL
missing PROPSYM definition repaired.
rww
∂22-Nov-76 1150 FTP:GJS at MIT-AI (Gerald Jay Sussman )
Date: 22 NOV 1976 1449-EST
Sender: GJS at MIT-AI
From: GJS at MIT-AI (Gerald Jay Sussman )
To: jmc at SU-AI
Message-ID: <[MIT-AI].30008>
I have an indication that you sent me some mail recently, but I don't have the
mail. I don't know what happened to it, so if it's important (or interesting)
please resend it. Thanx -- I'm sorry for losing it.
It was a batch of comments on your second SCHEME paper, and I'll try
to find them and resend them. Please acknowledge this message, however,
because, as far as I can see, the messages were properly sent, and
I don't want to be shouting down a well again.
∂22-Nov-76 1224 FTP:GJS at MIT-AI (Gerald Jay Sussman )
Date: 22 NOV 1976 1523-EST
Sender: GJS at MIT-AI
From: GJS at MIT-AI (Gerald Jay Sussman )
To: jmc at SU-AI
Message-ID: <[MIT-AI].30030>
I received it. The well is covered!
∂22-Nov-76 2120 SAU via AMET Terminal location(s)
To: LOTS.DIS[P,DOC]:;
What is the present plan for terminal locations? I haven't heard anything since
my complaint about 303.
∂23-Nov-76 1400 JMC*
Tell Stanford about Vera.
∂23-Nov-76 1900 JMC*
Call Siegler
∂23-Nov-76 2322 RWW BUG
All known bugs with respect to conditional expressions are gone.
I have not yet implemented the substitution rule we talked about.
also tauteq does not yet work with if_then_else terms but I expect
to fix that tomorrow.
rww
∂24-Nov-76 1518 RPG Debug/Step (SAIL)
To: MACLSP.DIS[AID,RPG]:;
DEBUG now knows about STEP in that while inspecting
stack frames, DEBUG will ignore all frames associated with the
single stepping facility.
∂24-Nov-76 1937 RWW BUG
THE TAUT NOW WORKS!!!! MAYBE THIS TIME WE HAVE THEM ALL.
RWW
Not unless you've debugged it.
∂24-Nov-76 2207 PMF TTY11
I managed to get it to work. (DON knew how.) First "ru hang[p,ted]" to make
it hang up. Then "ru dial[p,ted]". Say no to voice call and give it a phone #.
Say <ctrl>E (capital E seems important) and then dial tty11 will work.
Thanks, I'll try it.
∂25-Nov-76 0213 REM at TTY11 0213
For money, job at SU Magnetic Resonance Lab; not for money, continued minimal support of SU-AI software. P.S. Liz is living with her b.f. this fall.
∂25-Nov-76 0331 REM via AMET Dialer
It's been doubly broken nearly a year, how come it's not getting fixed?
(1) Bad interrupt, requires special program DIAL[P,TED] that uses status
instead of interrupt. (2) Cannot dial numbers beginning with "9" at all.
∂25-Nov-76 1506 BPM Service level
To: JMC
CC: JBR
∂25-Nov-76 1109 JMC Abuse of service level system.
Jeff considers that you have been abusing the service level
system to get an advantage over others. What exactly are
you doing now and what have you been doing?
I reserve small amounts (5%) of service level from batch so that I don't
have to do it by hand everyday. LES and ME have already discussed this
with me and decided to not allow RSL to be run from batch.
∂25-Nov-76 2244 FTP:MRC at MIT-AI (Mark Crispin ) ITS DFTP
Date: 26 NOV 1976 0143-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: ITS DFTP
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31319>
ITS DFTP has been (finally) finished. The old one is called
ODFTP, but it will go away imminently, as soon as CCA gets
the files there copied over to the new datacomputer.
Differences: [1] files are entered in Tenex format, ie fn1.fn2, [2]
it is now not possible to enter either Sname or device name,
[3] entire structure has undergone major modifications.
.info.;dftp order has as best documentation as is available; mostly
the old doc file with a very brief update page on top. I have
been promised documentation "any day" now for 4 weeks... anyway,
I'll announce ITS DFTP to the ITS world when I get the
documentation stashed away on .info.;...
Enjoy!
Mark
∂26-Nov-76 1257 FTP:MRC at MIT-AI (Mark Crispin )
Date: 26 NOV 1976 1555-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31483>
As system messages on SAIL and ITS announce, the DFTP documentation is
finally here. Enjoy!
∂26-Nov-76 1324 RPG TRACE/STEP(SAIL)
To: MACLSP.DIS[AID,RPG]:;
The Step package now UNTRACes any function it has to
single step through. Step will print a message informing the luser
of any UNTRACEs performed.
-rpg-
∂26-Nov-76 2119 FTP:MRC at MIT-AI (Mark Crispin ) New DFTP from CCA
Date: 27 NOV 1976 0018-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: New DFTP from CCA
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31608>
CCA distributed a new DFTP which I just installed on ITS
and SAIL. There are some bug fixes to what users have
complained about recently, and two minor external changes:
[1] QUIT requires confirmation.
[2] No password query on original attach; if you have a
psw protected node, you will be logged in as DFTP.GUEST.
This is because version 3 Datacomputer(they're already
talking about v.3...) will not allow LIST without LOGIN
and so no way to determine if login failure due to bad node or
bad password. To get to your node if you are attached as
DFTP.GUEST, do:
*attach <<<suai>foo>:mumble
if your user name is foo and psw mumble. [Of course, that is
for a Stanford person, but I don't know of any ITS users
with passwords.]
People without passwords will not be affected by this; they
will continue to have autologin as always.
∂26-Nov-76 2128 FTP:MRC at MIT-AI (Mark Crispin ) correction
Date: 27 NOV 1976 0027-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: correction
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31611>
The incantation is:
*ATTACH <<<SUAI>FOO:MUMBLE
not
*ATTACH <<<SUAI>FOO>:MUMBLE
(the psw will not be echoed).
Sorry.
∂26-Nov-76 2208 FTP:MRC at MIT-AI (Mark Crispin ) DCSTAT PROGRAM
Date: 27 NOV 1976 0106-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: DCSTAT PROGRAM
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].31618>
There now exists a DCSTAT program on ITS to give the CCA
status report about how the Datacomputer is(up, down, whatever).
A similar program will eventually exist for sail.
∂27-Nov-76 2154 JMC bug in spindl
Please explain whether what should be done about files previously spindled
and whether the new version will properly uncrunch and unspindle old files.
[REM - See mail to WD or JLS. Loss of '200 words at end of a page
occurs during crunch (possibley also spindle-without-crunch) and
cannot be recovered if anything has been written later in that spindle.]
∂28-Nov-76 1602 FTP:MRC at MIT-AI (Mark Crispin )
Date: 28 NOV 1976 1859-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].32004>
New Datacomputer is up again...I've decided to replace the current
ITS DCSTAT program with the CCA one running on TENEX
and Bottoms-10(when I can make a listing of it); for now, I will
write a quick equivalent to the ITS one for SAIL so if DFTP
behaves funny, you can get the CCA message about what's up.
∂29-Nov-76 1219 100 : Queenie Trip to Las Vegas
Confirmed plane reservations - San Jose to Las Vegas (12-5/Sunday),
leave 6:45PM - arrive 7:48 - Your return was left open. Reservations
at Holiday Inn, South - about one block from MGM Grand Hotel. Reserved
a compact car also. Ralph and Maurice on same flight, and Holiday Inn.
∂29-Nov-76 1303 FTP:MRC at MIT-AI (Mark Crispin )
Date: 29 NOV 1976 0349-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].32146>
DCSTAT now exists on SAIL as well as ITS.
∂29-Nov-76 1422 RWW Dan Blum (DSB)
Dan has been writing system type code for FOL, and asked if he could
possibly sign up to get credit for this work as a special project. I
said that I would ask you about it. He seems anxious to do things
more of a systems nature, but I think he may be a valuable help. Do
you have any ideas of how you would like him used. I though that
there might be some better display things he could do. I am trying
to think of a more directly research oriented task but haven't thought
of any. rww
}
I thought we agreed to get him to take over simplification.
∂30-Nov-76 0308 LES Farrel
Cordell requested that we leave him on. He is supposedly working on a thesis.
We shouldn't give our machine away for documentation purposes.
Please ask me in the future.
∂30-Nov-76 0313 LES
I will be happy to refer all requests for machine access to you.
ok, do it for a while
∂30-Nov-76 0909 CCG farrell
Farrell's work is of some interest to me. Comparable to, say, Randy
Davis. Sorry I wasn't more aware of the burden to the lab. I promise
it was not intentional, whatever it was. Now I wonder what he told you
or Les. If you want him deleted from the xgp list, do so.
Contritely,
Cordell
∂30-Nov-76 1245 RWW
There are two people involved
AMR Andrew Robinson (a new graduate student assigned to FOL)
DSB Danial Blum (an undergraduate)
I thought we previously talked about AMR, yesterdays note was about
DSB. We should talk about both of them.
∂30-Nov-76 1401 DCL
To: JP, RWW, ZM, JMC
***********************************************************************
VERIFICATION GROUP MEETING THURSDAY 2ND DEC.
PLACE A.I.LAB CONFERENCE ROOM
TIME 3.00 pm.
SUBJECT: VERIFYING MONITORS
SPEAKER: Susan Owiki
∂30-Nov-76 1410 DCL
To: ZM, RWW, JMC
***********************************************************************
VERIFICATION GROUP MEETING THURSDAY 2ND DEC.
PLACE A.I.LAB CONFERENCE ROOM
TIME 3.00 pm.
SUBJECT: VERIFYING MONITORS
SPEAKER: Susan Owiki
∂01-Dec-76 0959 CCG pub
Yes, why krd? Doesn't feigenbaum have enough money?
cordell
∂01-Dec-76 1618 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) SCHEME
Date: 1 DEC 1976 1918-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
Subject: SCHEME
To: jmc at SU-AI
CC: GJS at MIT-AI, GLS at MIT-AI
Message-ID: <[MIT-AI].33681>
It is true that a LABELS does not necessarily deliver up a "function
symbol". The result of defining one or more functions with LABELS
is that the functions are defined in a mutually recursive environment,
and the body of the LABELS is evaluated in that environment.
You evidently misunderstood the description of LABELS, for in
your example you used it in functional position anyway, and also
omitted the body and a level of parentheses. (Also there was
a missing parenthesis at the end! I wish you would grind (pretty-print)
your code!) A correct way to write the example is:
(maplist u (labels ((ff (lambda (y)
(cond ((atom y) y)
(t (ff (car y)))))))
ff))
That is, ff is defined in an appropriate environment, such
that its body can refer to ff, and then ff is the value of
the labels (as explicitly specified by the body).
We defined LABELS the way we did because it is extremely
painful to use LABEL to create two mutually recursive
functions, and it is so trivial to use LABELS to do the work
of LABEL.
I understood but misprinted and further didn't have the documentation.
However, I didn't think of making the function the value of the
labels, and this meets my objections - at least the practical
objection. The possible further objections would probably apply
to the original form of label also.
∂01-Dec-76 1649 FTP:GLS at MIT-AI (Guy L. Steele, Jr. ) scheme
Date: 1 DEC 1976 1948-EST
Sender: GLS at MIT-AI
From: GLS at MIT-AI (Guy L. Steele, Jr. )
Subject: scheme
To: jmc at SU-AI
CC: GJS at MIT-AI, GLS at MIT-AI
Message-ID: <[MIT-AI].33694>
I think you are right about LABEL and LABELS -- they are
both very screwy objects. You said you didn't have documentation;
did mean "not immediately at hand" or "not at all"?
In the latter case, let me know and I'll send memo 349 to you
posthaste.
∂02-Dec-76 0048 CG write up on knowledge and ignorance
A draft of the write up which is incomplete, but which nonetheless includes
essentially all of the technical material, exists on NP[KNO,CG]
∂02-Dec-76 0646 FTP:GJS at MIT-AI (Gerald Jay Sussman )
Date: 2 DEC 1976 0946-EST
Sender: GJS at MIT-AI
From: GJS at MIT-AI (Gerald Jay Sussman )
To: jmc at SU-AI
Message-ID: <[MIT-AI].33869>
thanx for resend. I read the exchange between
you and Steele. Please contact us for any further comments.
∂02-Dec-76 0704 FTP:GJS at MIT-AI (Gerald Jay Sussman )
Date: 2 DEC 1976 1004-EST
Sender: GJS at MIT-AI
From: GJS at MIT-AI (Gerald Jay Sussman )
To: jmc at SU-AI
Message-ID: <[MIT-AI].33879>
hi, by the way. Did u ever read AI-Memo 380 (Foward Reasoning and Dependency-directed
Backtracking in a program for Computer-Aided Circuit Analysis)? I would love to have
your comments on that.
No, could you U.S. Mail me a copy of AI 380?
∂02-Dec-76 0953 PAT
∂02-Dec-76 0857 QIB
BETTY SCOTT CALLED TO SAY THAT JOHN'S PERSONAL STATUS, I.E. MARRIED, HAS
BEEN DONE, ALSO BETTY REQUESTED A COURTESY CARD FOR JOHN'S WIFE. BETTY
NEEDS TO KNOW WHETHER OR NOT JOHN WANTS TO CHANGE HIS WITHHOLDING STATUS
TO REFLECT THE MARRIED STATUS. IF SO, HE'LL NEED TO FILL OUT A NEW
WITHHOLDING TAX AND PAYROLL DATA FORM. HAPPY THURSDAY!
∂02-Dec-76 1432 RPG
∂01-Dec-76 2057 JMC
JBR says stack I-O has been in this system for three years.
Yes, but Maclisp hasn't. Such functions as (INPUSH ..), which
pushes an open input file onto the stack, have yet to be written.
-rpg-
∂02-Dec-76 1437 RPG NCOMPLR/TOPS-10
To: MACLSP.DIS[AID,RPG]:;
The ncomplr now parses file names in winning line mode.
In addition, full decoding of files is now
available. Thus you can say:
FOO.FAS[LO,SER]←FOO.LSR[BLE,TCH](KT)
and all will be well.
∂02-Dec-76 2230 MRB via MAXC Display proposal
I've looked at you draft of the proposal and have the following observations:
1)You may need to justify more the "need for unique or dedicated equipment";
the proposal seems to provide computing capability only. Our only leg to stand
on here seems to be the need to centralize the department while using far-
flung computing equipment. Otherwise we must bill the system as a research project
in itself, which it could be if we had some investigators here who could pursue research in the area of networking, graphics interfaces
and the like.
2)Can we really get a SLOT printer from Xerox? Can we get an IMP port from ARPA?
3)The proposal is due in less than a month and a half. It shouldn't be too hard
to come up with a reasonable sketch of the system and its costs, but the more difficult
problem seems to be getting appropriate statements from department faculty about their
research, since the NSF claims to place great emphasis on this aspect of the
proposal.
I am willing to put in some bounded amount of effort on technical aspects of the
proposal. I must defer, however, when it comes
to political problems (e.g., rounding up faculty reports) or secretarial duties. I will
try to talk to JBR and perhaps Gio in the next few days.
The technical area is where your help will be useful. I
think perhaps I'll get Feigenbaum to sound them out as to whether the
proposal will fly.
∂03-Dec-76 1048 CCG Nishino
I receivd a letter from Dr. Nishino, the ETL and PIPS director.
He's visiting and wants to seeyou. Icouldn't tell from his letter whether
he also wrote you, or expected me to schedule the appointment. Seems
like his plan is to visit the ai lab on monday, dec 13, in the morning.
Are you in touch with him or should I coordinate your appointment?
cordell
I'm not in touch.
∂03-Dec-76 2332 FTP:MRC at MIT-AI (Mark Crispin ) For your information
Date: 4 DEC 1976 0226-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: For your information
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].34620>
The following is a blurb from CCA about the new DFTP and might
explain some of the ideas behind the current design:
Date: 26 NOV 1976 1439-EST
From: JF at CCA
Subject: RELEASE OF NEW DFTP
To: DFTP LIAISONS:
cc: ROTHNIE
A new version of DFTP is being installed at all sites. This
version is compatible at the command level for most users.
However, there are a number of extensions and changes in
relatively infrequently used parts of the system; people who
make extensive use of subdirectories (using the CONNECT command)
may find themselves particularly affected.
Documentation for the new version exists in both the old and
new versions of DFTP. In the old, it can be retrieved by the
following sequence:
@(O)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP.NEW-MEMO
[OK]
*QUIT
In the new version:
@(N)DFTP
[ATTACHING]
*GET <<<COMMON>DFTP>NEW.DOC
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
(SXCFS: STAGING DATA FOR FILE = DFTP.COMMON.DFTP."<FILES">)
{OK}
*QUIT
The new version of DFTP is distinguished by several
features:
1. Availability. New DFTP runs on ITS, SAIL, TENEX,
TOPS-10, and TOPS-20 systems; it is also being
implemented on MULTICS.
2. Capacity. New DFTP uses a mass store, an Ampex Terabit
Memory System (TBM). This device currently provides an
on-line capability of about 200 billion bits, expandable
up to 3.2 trillion (10**12) in the full configuration.
As a consequence, most users have had their allocations
increased. As another consequence, users may expect
noticeable delays when they first access data, as it is
moved from tertiary to secondary storage. These delays
may range from a few seconds to several minutes; they
will be signalled by a message like the one appearing in
the example above.
3. New storage structure. The new DFTP collects files for
a user into one or more large Datacomputer files. This
new organization is much more space-efficient than the
old; it should also serve to minimize delays for staging
from tertiary storage.
4. Extended functions. Several new features follow from
DFTP's new file organization:
a. File Sets. Commands which refer to files may now
specify a set of files in place of a single file,
by use of an asterisk in a file name field. This
operates like a "wild card", matching any value
in that field. For example,
*PUT FOO.*
(FOO.DOC)
(FOO.MAC)
(FOO.REL)
(FOO.SAV)
stores all four files in the user's directory
which have a first name of "FOO", with a single
command.
b. File version numbers. DFTP now maintains an
internal version number, so that several
different version of the same file may be kept
and retrieved individually.
c. DELETE, UNDELETE, and EXPUNGE. The effect of
DELETE is now revocable; until an EXPUNGE
command is executed, deleted files may be rescued
and returned to normal status. EXPUNGE should be
a fairly infrequent operation, used to reclaim
space when an allocation is filled with unwanted
files.
d. Increased directory information. The amount of
information kept with a file has been increased
significantly. DFTP now keeps a local write
date, a DFTP store date, file bytsize, length in
bytes, full-length file names, and a checksum.
This information contributes added convenience to
users. It also provides full-circle integrity
checking, with the same checksum computed and
checked throughout the file's handling by DFTP.
Full decscriptions of these and other aspects of the new DFTP
are contained in the document mentioned above.
∂06-Dec-76 1100 JMC*
Call Reynolds about number.
∂07-Dec-76 0018 FTP:MRC at MIT-AI (Mark Crispin )
Date: 7 DEC 1976 0316-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].35285>
New version of DFTP up on ITS and SAIL. The only change is that
password query is restored for users who have a password protected
node for all access: I pointed out to WRB@CCA that it was possible
to check 'cause the error message would be different, so he put
it all back in with the checking of the error message. So if you have
a password protected node, autologin will work again.
(Of course, if password is for write access only, then autologin will
log into the read-only protection level).
Mark
∂07-Dec-76 1033 LES For your consideration.
∂07-Dec-76 0929 JFR via IMSSSS
SDD (Scott Daniels) of IMSSS deserves an account for Sail work.
∂07-Dec-76 2307 DCL
To: JP, JMC, RWW
***********************************************************************
VERIFICATION GROUP MEETING THURSDAY 9TH DEC.
PLACE A.I.LAB CONFERENCE ROOM
TIME 3.00 pm.
SUBJECT: VERIFYING KNUTH'S INSITU PROGRAM
SPEAKER: Wolfgang Pollak
The question is: can Wolfgang convince us?
This will be a short talk starting promptly at 3.00. It will raise
questions to do with quantification (or the lack of it) in the verifier.
In his 1971 IFIP address Knuth states "the program seems to be beyond
the present stage of automatic program verification techniques".
After we will have a SHORT system meeting.
Next speaker: Jay Spitzen of SRI provided there will be enough attendance.
∂08-Dec-76 0103 REM via AMET
Have you been able to get the dialer to work? I can't, and DIAL[P,TED] has been sabotaged too.
∂08-Dec-76 1100 JMC*
Denicoff comments are ok.
∂08-Dec-76 1438 MFB SAMEF
(WITHOUT TESTING) YOUR PROGRAM SEEMS STRAIGHTFORWARD AND CORRECT. I WONDER
WHAT THE ORIGINAL INTENT OF THE 'SAMEFRINGE PROBLEM' WAS. WAS IT TO TAKE
A FAMILIAR PROGRAM (FLATTEN) AND COROUTINE IT? SEEMS HARD TO BELEIVE
THAT NO ONE HAS WRITTEN THIS PROGRAM BEFORE. -MARTIN BROOK
∂08-Dec-76 1514 RPG INPUSH/INPOP/SAIL
To: MACLSP.DIS[AID,RPG]:;
The SAIL Maclisp now sports INPUSH/INPOP, which can be
used to do stack-structured input. Delicately based on the
IOPUSH/IOPOP/MTAPE UUO's at SAIL, they can be used as follows:
***FOO.BAR***
.
.
.
'CIAO
(INPUSH LOSING FLE)
'BACK-AGAIN
.
.
.
***LOSING.FLE***
.
.
.
'HI-THERE
(INPOP)
.
.
.
Then (EREAD FOO BAR DSK (LO SER)) produces:
.
.
.
CIAO
(DSK (LO SER)) ;value of (INPUSH ...)
.
.
.
HI-THERE
T ;due to (INPOP)
BACK-AGAIN
.
.
.
Notice that (INPOP) has to occur in the file: simply letting
(READ) run off the end fails! To remedy this, there is a function
called REQUIRE (given an autoload property by (HELP), which will
(PRINT (EVAL (READ))) everything in the file which is REQUIRE'ed.
It is called as: (REQUIRE LOSING FLE DSK (LO SER)) i.e. it has
the same arguments as UREAD. The NCOMPLR also knows about REQUIRE,
and the proper thing to do is:
(DECLARE (EVAL (READ))
(REQUIRE LOSING FLE DSK (LO SER))
which will work whether the file is being read or compiled.
I would discourage the use of these functions, however,
since they depend on black UUO magic and will possibly disappear
with the onslaught on NEWIO around Armageddon.
∂08-Dec-76 2120 FTP:CARL at MIT-AI (Carl Hewitt )
Date: 9 DEC 1976 0020-EST
Sender: CARL at MIT-AI
From: CARL at MIT-AI (Carl Hewitt )
To: jmc at SU-AI
CC: CARL at MIT-AI
Message-ID: <[MIT-AI].36024>
Dear John,
The same-fringe problem is to check whether or not
two trees have the same fringe without calling any "extraneous"
functions such as CONS. The idea is that you can test two trees
for equality with out calling any extraneous functions so why should
it be necessary in order to test if two trees have the same fringe.
The solution you sent me uses CONS the points marked by an asterisk.
(DEFPROP SAME
(LAMBDA(X Y U V)
(COND ((ATOM X)
(COND ((ATOM Y)
(AND (EQ X Y)
(COND ((OR (ATOM U) (ATOM V))
(EQ U V))
(T
(SAME (CAR U) (CAR V) (CDR U) (CDR V))))))
(T
* (SAME X (CAR Y) U (CONS (CDR Y) V)))))
((ATOM Y)
* (SAME (CAR X) Y (CONS (CDR X) U) V))
(T
* (SAME (CAR X) (CAR Y) (CONS (CDR X) U) (CONS (CDR Y) V)))))
EXPR)
(DEFPROP SAMEFRINGE
(LAMBDA (X Y) (SAME X Y NIL NIL))
EXPR)
The above implementation is fairly well known by
people who have looked into the problem. Your argument that
this implementation does not use any more storage because
SAME is iterative is original so far as I know.
[As an aside, it should not be necessary for you to compile
the function SAME for it to be iterative. If you implement
your language using message passing semantics then the
the function SAME should be iterative in all of its implementations.]
However, your argument makes the assumption that the two trees whose fringes
are being compared are not needed afterward. If the two trees
are needed then the above solution does CONS up more storage
in the course of the computation.
It is possible to implement same-fringe using an extra amount of space
that is only proportional to the logarithm of the maximum depth of the trees.
However, this solution slows down the processing by a factor of the
logarithm of the depth of the tree.
In LISP 1.5 (on the 7094) it is possible to implement same-fringe using FUNCTION.
The most elegant solution is to use normal order evaluation. The following is
a valid solution using normal order evaluation for LISP:
(DEFPROP SAME-FRINGE
(LAMBDA (TREE1 TREE2)
(EQUAL (FRINGE TREE1) (FRINGE TREE2))))
(DEFPROP FRINGE
(LAMBDA (TREE)
(COND
((ATOM TREE)
(LIST TREE))
(T
(APPEND (FRINGE (CAR TREE)) (FRINGE (CDR TREE)))))))
Actually the normal order evaluation of arguments can be confined to the function CONS.
In this case the usual recursive definition of APPEND can be used:
(DEFRPOP APPEND
(LAMBDA (L1 L2)
(COND
((NULL L1)
L2)
(T
(CONS (CAR L1) (APPEND (CDR L1) L2))))))
It is an open problem in comparative schematology to prove
that there is no set of recursive equations [which are uninterpreted
except in the use of EQ, CAR, and CDR] which can implement
SAME-FRINGE.
I would be curious as to your reaction to all of this.
Sincerely,
Carl
∂09-Dec-76 0110 CG BB
I just changed it;I was about to check whether the change was correct.
Question: A student or two has asked me for a copy of your notes on
proving theorems about LISP; do you have extra copies lying around?
If not I'll spool the stuff and xerox it.
Better check the change, because I tried it right away. I don't know
where the extras are, so in case I can't find it tomorrow morning,
please xs theory.xgp[f76,jmc] and xerox a couple.
∂09-Dec-76 0154 FTP:Geoff at SRI-AI FYI
Date: 9 Dec 1976 0151-PST
From: Geoff at SRI-AI
Subject: FYI
To: JMC at SAIL
Mail from OFFICE-1 rcvd at 8-Dec-76 1645-PST
Date: 8 DEC 1976 1644-PST
From: PANKO at OFFICE-1
Subject: Carter's Use of Computer Message Service (with compliments of Ron Uhlig, who found this article)
To: [ISI]<MsgGroup>Mailing.List:
cc: rulifson at PARC-MAXC, taylor at PARC-MAXC,
cc: sutherland at PARC-MAXC, schlesinger at PARC-MAXC,
cc: metcalfe at PARC-MAXC
< PANKO, CARTER.NLS;3, >, 8-DEC-76 15:17 RA3Y ;;;; .YBL=1; .YBS=2;
.PN=0; .PES;
COMPUTER TIED CARTER, MONDALE CAMPAIGNS
The Bethesda Connection
By John Holusha, Washington Star Staff Writer
Jimmy Carter was sometimes described as the "computer-driven
candidate" during his determined quest for the presidency.
Along with computerized cost controls, the Democratic candidate had
terminals humming in both his and running mate Walter Mondale's
airplanes as they crisscrossed the country. It was the computer that
kept track of each other's schedules and--more importantly--kept tabs on
what each was saying to avoid embarrassing contradictions.
If Mondale wanted to know what Carter was saying on tax reform, all
he had to do was have an aide punch a few keys and the machine would
come up with all his speeches on the subject.
Similarly, if Carter wanted to get a message to Mondale, the
fastest way was often was to punch it into the computer. As soon as the
chartered campaign plane landed, it would connect up with the computer
and all incoming messages would be printed out.
As far as the staff on the planes were concerned, they were
checking in with Atlanta headquarters. Actually, everything in the
system--from the Atlanta operation to the candidates themselves anywhere
in the country--was being funneled through a very powerful computer
located on the third floor of the Suburban Trust building in Bethesda.
The system is the brainchild of John McCann, an aggressive
executive of the company that owns the computer, Scientific Time Sharing
Corp. McCann is a 20-year veteran of the computer industry and a
onetime amateur politician.
"I had done a lot of work for Norman Cousins in the preliminary
organization for the Muskie campaign four years ago," McCann says. "I
knew what could be done and I had a personal interest."
McCann didn't have any contacts in the Carter camp. So he started
off in mid-June with a letter to Dr. Peter Bourne, who had been
mentioned in press accounts as one of Carter's inner circle.
He was shortly invited to Atlanta to meet with chief systems
analyst Stephen Slade. "Within two weeks I had a contract."
Altogether, the computerized communications system cost the
campaign about $5,000. "They got a good deal," McCann said. We didn't
know much about pricing so we did it on a per message basis. So they
sent a relatively few long messages rather than a lot of shorter ones."
McCann says the campaign workers had a strong sense of history.
They wanted hard copies (computerese for something on paper) of
everything for archival purposes. This system generated hard copies of
all communications."
The way McCann's own company uses computer communications gives
some idea of what the future holds. The system is called the "Mailbox"
and all an individual sees is a modern electric typewriter with some
extra keys.
One person in the company "deposits" a message in the mailbox by
punching in a few codes and then writing out the message. It can be
addressed to one other person, several or everybody on the system.
Company employees check with their terminals once or twice a day to
see what has been "deposited" for them. The machine prints them out in
descending order of priority.
The result is that face-to-face communications, old fashioned
talking in the halls, is becoming rare in the company. The president
might be in Bethesda, but the executive vice president is in Los Angeles
and other key executives are spread across the country.
"To an extent we're becoming the victims of our own copper
umbilicals," McCann observes.
Although he said Carter has shown clear acceptance of modern
computer technology, McCann is going to go slowly in pushing it on the
White House.
"When that story appeared saying all the resumes were going into a
computerized data bank to match them up with jobs, I heard he reacted
very strongly," McCann said. "He didn't want to give the impression
some robot was making decisions."
McCann says he'll try to sell the White House on things similar to
those that worked during the campaign: scheduling and information
sorting.
"Say the press office wanted some selective information, all the
latest on Israel for instance. You could have hard copy almost
instantly. Or if you wanted to know where the Treasury secretary was
going next week and what he was going to speak on. It would all be
available."
So far McCann hasn't gotten any response because the Carter
campaign staff has dispersed and the transition staff is just getting
organized.
"I'll be in touch with Carter's people," McCann says," as soon as I
find out who they are."
Washington Star, November 21, 1976, p. A3
-------
-------
∂09-Dec-76 1040 RPG SAMEFRINGE
The minor bug was in my brain: I assumed that it was
supposed to operate on LIST's, not trees. If you change all expressions
in calls to SAME from (CONS (CDR a) b) to (COND ((CDR a)(CONS (CDR a) b))
(b))
then your solution is exactly equivalent to Finin's (given that SAME
is re-coded iteratively).
∂09-Dec-76 1405 RDR via AMET <mccarthy>taskss@LOTS
May I post a listing oof this file and/or point to it in a file
I am making with similar but more mundane(i.e., probably no good for credit)
projects LOTS would like to see? There really have been a lot of
potential volunteers which we haven't been set up to accomodate. By
now it is late enough that, no matter what, to be ready for next quarter,
we need to get some people on the system using it constructively (I mean besidess
the staff.)
I want to check with Ralph before I post it, because it may be
that a bunch of eager users would interfere with getting the machine
ready for Winter quarter. Assuming he assents, we can post it - or
a revised version - this weekend.
Incidentally, I check mail in LOTS frequently enough for that to
be reliable.
∂09-Dec-76 1611 ND samefringe vs flatten
an approximate equivalence proof is on flat(2)[fr,nd]/n.
∂11-Dec-76 0124 LES BUREAU.1
Has the right flavor, but some clarification is needed.
1. You tell them to send it to HVA. This makes sense only if she is
to make the decision normally. If not, it should be sent to that person.
2. The "Proposed login identification" should also say "2 or 3 letters".
It would also be a good idea to suggest that they test whether the
desired identifier is in use by saying "FINGER <pn>" to the system.
3. You ask them how their use will "advance objectives of AI Lab",
but these objectives are not stated, nor is a reference provided.
Besides, we have admitted a large number of people whose work
fairly clearly does not advance the objectives of the AI Lab, but happens
to be of interest to us. I would suggest something vaguer, such as
"Why should the conduct of this work be of interest to the AI Lab."
4. For people at Stanford, we should ask why it is impractical for
them to use LOTS, SCIP, or other public facilities.
5. A version of this form should be kept in a public place (e.g. [UP,DOC])
and referenced in the HELP LOGIN message (there is already a
summary of the account request procedure there).
∂11-Dec-76 1636 FTP:MINSKY at MIT-AI (Marvin Minsky )
Date: 11 DEC 1976 1935-EST
Sender: MINSKY at MIT-AI
From: MINSKY at MIT-AI (Marvin Minsky )
To: jmc at SU-AI
Message-ID: <[MIT-AI].37175>
telephone paper is in minsky;btl >
∂12-Dec-76 2135 MFB SAME FR
WELL, AN ERROR OF INTENT (THINKING SAMEFRINGE WAS EQUIVELENT TO EQUAL) AND A BASIS
BLUNDER (NOT REBUILDING CORRECTLY). THE ONLY SOLUTIONS I CAN THINK OF THAT DONT CONS
BUT RATHER RPLACA DO NOT WORK IF THE ARGUMENTS SHARE STRUCTURES, AND WORSE,
HAVE THE REBUILDING IMMEDIATELY AFTER THE RECURSIVE CALL WHERE THE ARGUMENT WAS
RPLACA'D, AND THEREFORE CANT BE ITERATIVELY COMPILED. (ALTHOUGH THE PROBLEM
COULD BE SOLVED ONLY USING NEW STACK CELLS THAT WAY). DOES ANYBODY HAVE A PROOF
THAT ONE MUST USE SOME NEW CELLS SOMEWHERE? IS THAT TRUE? (SEEMS SO TO ME)
MARTIN BROOKS
∂12-Dec-76 2332 MFB SAMEFR
ANOTHER TRY AND SOME COMMENTS IN SAME.FR [M,MFB] -MARTIN B.
∂13-Dec-76 0245 DCL
DO YOU HAVE A PRECISE OBJECTION TO CORKY'S THESIS NOW?
Pas encore. Demain, peut-etre.
∂13-Dec-76 1138 RWW CONDITIONAL EXPRESSIONS
To: FOL.DIS[FOL,RWW]:;
Something is broken with conditional expressions and TAUT. I don't
know what it is as I only found it this morning. Any incorrect examples
you find you can send to me. Sorry.
rww
∂13-Dec-76 1406 RWW CONDITIONAL EXPRESSIONS
To: FOL.DIS[FOL,RWW]:;
It was rww that was broken. He is now fixed (???). Please ignore
previous note.
rww
∂13-Dec-76 2202 REG
By the way, REM is now hanging around at LOTS.
∂13-Dec-76 2340 DCL
MAINTENANT, DEMAIN EST AUJOURD'HUI
∂14-Dec-76 1050 REP CS-258
I am trying to arrange to take CS-258 during Winter Quarter but apparently
they have resceduled Tarjan's Computability course to meet at the same time. Do
you think that it will be possible to modify the time that your course meets? I
have made the same request to Tarjan.
Rich Pattis
I'm pretty sure something can be worked out.
∂14-Dec-76 2113 FTP:MRC at MIT-AI (Mark Crispin )
Date: 15 DEC 1976 0012-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].38649>
DCSTAT now will give some more information. Try it and see! Complaints
to DEE@CCA.
∂14-Dec-76 2221 RPG Printing windows/SAIL
To: MACLSP.DIS[AID,RPG]:;
One can now print the window surrounding a CE by
saying "W" to the Editor. If the windowsize is 2, then the
2 tokens preceeding the CE, the CE, and the 2 tokens following
the CE are printed (a token is an expression or a parenthesis).
The windowsize is set by (WINDOW n).
∂15-Dec-76 0017 NS
To: JMC
Your following News Service notification
request(s) will expire within a week:
(bulletin)/AP/NYT
∂16-Dec-76 1547 RPG
∂16-Dec-76 0200 JMC Editor in Maclsp
I would like to be able to change the CE to a certain function of it,
edit this altered expression, then apply the inverse transformation
to get a change CE as part of the function being edited. Example:
if I can pseudoprint the CE so that the parentheses become the
atoms L and R, I can correct parenthesis misprints much more easily.
It isn't clear whether this is feasible.
Say:
(EDITCOMMAND FOO (%EVALUATE (LIST 'CR (<FUNCTION> %#CE))))
(EDITCOMMAND FOO-1 (%EVALUATE (LIST 'CR (<FUNCTION-1>) %#CE)
Then "FOO" to the editor will replace the CE with <FUNCTION>
applied to it. "FOO-1" will replace it with the inverse.
If you make up a file called EDIT.INI with these expressions in
it, they will always be defined when you edit.
∂17-Dec-76 1632 MDD Minimal entailment
For additional copies:XS REP.XGP or PUB REP. I haven't tried to indicate
who did what. Feel free to use it any way you like.
∂19-Dec-76 2004 LES
∂18-Dec-76 1424 JAM MLB
I understand MLB (Marc LeBrun) expires at the end of the month. Could
we get him extended indefinitely (or at least for a long time)?
to you and John Chowning before doing anything about it. In particular,
such requests need to come from the Mu?ic Gup as such.
I am handling requests like that of extending MLB, but I need to talk
∂21-Dec-76 0017 LES Pressburger
∂20-Dec-76 2321 JMC
Have you pursued Pressburger?
As you may recall, we discussed the situation with TW in my office.
Terry said that he hadn't leaned on him yet but was thinking of
using him to put KRL on our system. I do not know if this plan is
being carried out yet.
∂21-Dec-76 0043 FTP:MRC at MIT-AI (Mark Crispin ) New versions of DFTP and DCSTAT
Date: 21 DEC 1976 0342-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
Subject: New versions of DFTP and DCSTAT
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].41004>
New versions of DFTP and DCSTAT on ITS and SAIL; these are CCA updates
reputed to have bug fixes and/or enhancements. Complain to
Bug-DFTP@MIT-AI if anything bad happens.
∂21-Dec-76 0907 PMF Datamedia simulator for imlacs
It is finished. However it takes a slight hardware mod. 3 wires have to be added
Anytime it is convenient I can do it. The old imlac software still works with
the change. If you want to try the simulator the imlacs are in the shop.
Well, I'm impressed and will try it out right away.
∂21-Dec-76 1037 FTP:ERDA at BBN-TENEX Second Berkeley Workshop
Date: 21 Dec 1976 1336-EST
From: ERDA at BBN-TENEX
Subject: Second Berkeley Workshop
To: Karp, Roberts, Pool, Burchfiel, Dodds, Tomlinson,
To: VITTAL at BBN-TENEXF, JMC at SU-AI, TW at SU-AI,
To: Alsberg at MIT-MULTICS, Amiot at MIT-MULTICS,
To: DAustin at MIT-MULTICS, BBussell at MIT-MULTICS,
To: BCampbell at MIT-MULTICS, GCampbell at MIT-MULTICS,
To: Day at MIT-MULTICS, Estrrin at MIT-MULTICS,
To: Franceschini at MIT-MULTICS, GARDNER at MIT-MULTICS,
To: JACQUES at MIT-MULTICS, MAP at MIT-MULTICS,
To: Pogran at MIT-MULTICS, MRose at MIT-MULTICS,
To: ERDA at MIT-MULTICS, Abbott at USC-ISI, Cerf at USC-ISI,
To: Crocker at USC-ISI, SU-DSL at USC-ISI, Farber at USC-ISI,
To: Kirstein at USC-ISI, Kleinrock at USC-ISI,
To: Licklider at USC-ISI, Lipinski at USC-ISI, RISOS at USC-ISI,
To: Walker at USC-ISI, Willis at USC-ISI, stotz at USC-ISIB,
To: White at USC-ISIC, Gary at ILL-NTS, METCALFE at PARC-MAXC,
To: SPROULL at PARC-MAXC, Geoff at SRI-AI, OMalley at SRI-AI,
To: Tenenbaum at SRI-AI, JM at MIT-MC, NEWELL at CMU-10A,
To: Cotton at NBS-10, Kimbleton at NBS-10, JF at CCA-TENEX,
To: Tom at CCA-TENEX, Rothnie at CCA-TENEX, Gaines at RAND-UNIX,
To: Sunshine at RAND-UNIX
Call for Papers for the
Second Berkeley Workshop on Distributed Data Management
and Computer Networks.
Date and Place: May 25-27, 1977 at LBL, Univ of Cal, Berkeley.
Program Cochairmen: Arie Shoshani/LBL
Michael Stonebraker, UCB/LBL
Program Committee:
Peter Alsberg, UI/CAC
Gerry Estrin, UCLA
David Farber, UCI
James Gray, IBM Research Center, Palo Alto
Dennis HAll, LBL
Steven Kimbleton, NBS
Leonard Kleinrock, UCLA
Alan Merten, Univ. of Michigan
David Richards, LBL
Jay Rothnie, DOD
Dianne Smith, Univ. of Utah
Dennis Tsichritzis, Univ. of Toronto
Suggested topics:
Distributed data base techniques; distributed data management;
distributed networks, local networks, and gateways.
Computer Network Architecture; computer network protocols;
user interface to computer networks; user interface to
distributed data management systems; data translation and
exchange; conceptual and semantic models of data; concurrency,
control, and resiliency of distributed data.
Submission of Papers: Papers should not exceed 4,000 words.
Send four copies by March 1, 1977 to
Arie Shoshani
Computer Science and Applied Mathematics Dept
Lawrence Berkeley Laboratory
University of California
Berkeley, California 94720
Tel: (415) 843-2740 ext 5171 or FTS 451-5171
Comments to Austin@BBN or DAustin@MIT-MULTICS
-------
∂21-Dec-76 1230 DPB
To: JMC, wiederhold at SUMEX-AIM
Ed asked me to find out how the terminal system proposal is
doing. Deadlines are approaching fast and I have seen nothing yet.
-Denny
∂21-Dec-76 1357 LES
∂21-Dec-76 1159 DPB
Les, We are starting to bring up the CSD files we need.
Disk quota either is or will become a problem.
What is the disk quotas on the directories we already have/
or how does one ask the system ( [CSD,MJL] [CSD,BS] [CSD,CET] [1,DPB] )
We now have CSD files all over:
about 50K of intro course materials on [CSD,SM]. (Scott McGregor is consolidating
handouts from all known intro course sources)
about 50K of Course Evaluation materials on [⊃MJC] (Programs, documaentation, etc.)
about 30K of Orientation materials somewhere (I don't know exactly what lives here.)
about 20K of CSD directory files and related junk on
[1,DPB] [CSD,MJL]
Scott has a SCIP tape with a variety of our stuff which he plans
to bring up early next quarter.
The intro course stuff will go to LOTS as soon as Scott has assembled,
and indexed it. Also most of the space above is now being used anyway so
the net impact on the system will be less than
it seems.
Bottom line: How much disk can you expect to give us
also Please do not kill SM when his current access expires, he will be
working for me for the rest of the academic year.
-Denny
∂22-Dec-76 0209 RDR via AMET LOTS status report
To: LOTS.DIS[P,DOC]:;
Well the LOTS KL-20 was delivered on November 9th. It was missing half
its 256K core and 1/3 its 48 DH11 ports. DEC says February for the core and
April if we're lucky for the DH11.
The system has been fairly stable, although slow with so little memory.
A lot of effort has been devoted to disassembling, modifying, and now
reassembling the 11-code for the front end so as to accomodate our
Printronix printer rather than the LP20. What a waste of manpower DEC
is causing there. For quite a while now, the 11 code has been
patched to cause console output to go to the Printronix, so we ca
get hardcopy out of the machine.
A number of courses will begin to make use of LOTS early in January.
Current problems with this include having a "real" LPT: available
in time, increasing the number of user directories from its current
limit of under 500 to at least its reported maximum of under
1500, and arrangements which have to be made for security of the building
we are in to permit access to the terminal evenings, nights, and weekends.
The SCRDT building will be our sole location for the time
being, as this is possible with the reduction in the number of ports.
As the people on the network have noticed, communicaion has become
irregular. If you send me a network mail request, I will add you
to the LOTS distribution list for our newsletter etc. This too
is irregular as yet (not having begun) but should soon improve.
∂22-Dec-76 1100 JMC*
buchan.le1
∂22-Dec-76 1204 TW via MAXC Sam's affair
In response to: ↑O21-Dec-76 1442 JMC Partee
Barbara Partee has three readings for "Sam thinks that Mary wants
him to have an affair with Bill's wife", and has challenged me to represent them in my first order concepts system.
-------
After thinking about this for a while, I decided that she is
strongly underestimating. I claim that there are 14 different
situations in which the statement could be validly made. This
situation arises because there are three processors involved, Sam,
Mary, and the person making the statement. Any one of these could
be the source of the description "Bill's wife", since it is embedded
inside the scope of "want" inside the scope of "think" in the scope
of the statement. Instead of putting this directly into KRL, I will
use a more traditional logical notation, but keep the same basic
structure. I would want to say that the speaker is making the
following claim:
Believes(Sam, \Desires(Mary, \HaveAffair(Sam Person1)))
Where the "\" character indicates quotation of a predication (in the
speaker's mental model), and the predicates "Believe" and "Desire"
have the following characteristic:
One of their arguments is a quoted predication, the other names
a person. There is a presupposition that the person has a belief
structure which can include a translation of the description.
Translations relate belief structures in two different mental
models, with predicates mapping onto corresponding predicates, and
individuals onto corresponding individuals. The assumption that such
a mapping is possible is in the mind of the person whose mental
model includes the predication of the belief. Of course, the set of
descriptions any one person has for an individual may not be in
one-one correspondence (via translation) with the set of
descriptions another person has for the corresponding individual.
Given this, the speaker can have any combination of the following
beliefs about Person1:
1 WifeOf(Person1, Bill)
2 Believes(Sam, \WifeOf(Person1, Bill))
3 Believes(Mary, \WifeOf(Person1, Bill))
4 Believes(Sam, \Believes(Mary, \WifeOf(Person1, Bill)))
I have been able to come up with contexts in which the sentence
could have been uttered as the result of 14 of the 15
possible combinations.
--------------
In all of these, I have used the name "Jane" to refer to the person
I have labelled "Person1", when pronouns get too confusing.
1 -- the reading which could be followed with "But neither one of
them knows she's married to Bill"
12 -- "But he knows that Mary doesn't know Jane is married to Bill"
13 -- "But he doesn't realize that Jane is Bill's wife".
123 -- "but he doesn't know that Mary knows Jane is married to Bill"
1234 -- the most likely reading, in which everybody is knowledgable
2 -- "But in fact, Mary knows that Bill isn't married"
24 -- "But he must have misunderstood her, because Mary knows that
Bill isn't married"
23 -- Mary said "go have an affair with Jane". Both Sam and Mary
think that Jane is married to Bill, not realizing that the
wedding was called off. It was supposed to be a secret
marriage, and neither Sam nor Mary knows that the other
knows the secret.
234 -- like the 23 case, except that Sam thinks that Mary knows the
secret
34 -- "which amuses him a lot, since he knows that Bill isn't
married"
134 -- "which amuses him a lot, since he doesn't realize that Bill
is married"
124 -- "and he says that Mary must know that she is Bill's wife"
4 -- Mary said "go have an affair with Jane". Sam knew that Mary
wanted revenge on Bill for an old hurt, and deduced that
she must believe that Jane is Bill's wife (which in fact
she doesn't).
14 -- like 4 alone, except that Jane really is Bill's wife
-------------
3 -- This one seems's impossible. It corresponds to a case where
the speaker believes that Mary thinks that Jane is Bill's
wife, but neither the speaker nor Sam knows this, and
neither the speaker nor Sam thinks that Mary is Bill's
wife. There seems to be no way for the quoted description
\WifeOf(Bill) to get in.
I think there are some additional problems having to do with whether
what is in question in any model is the existence of the person, or
the fact of being married. There should be a difference between "But
he doesn't know that she never married him" and "But he doesn't know
that Bill is a bachelor", and I don't think I have captured it here.
∂22-Dec-76 1252 DPB TA for cs258
John, Do you need a TA for cs258? and/or Have you found
anyone? I will assume that you don't need a TA until hearing from you (or
the TA chosen). -Denny
∂23-Dec-76 1214 TW via MAXC
no, but I would like to see a copy of it
∂23-Dec-76 1354 TW via MAXC more thoughts on Partee's example
On the number of ambiguities
A quick further look shows that the number of different beliefs possible
(like the ones labelled 1 2 3 4 above) is always 2**(n-1) where n is the
number of different belief systems involved. If every combination were
possible (except the combination which includes none of them), then the
number of ambiguities would be (2**(2**(n-1))-1. Since some seem to
be eliminated it doesn't grow quite that rapidly, but still probably
double exponential.
-----------
On possible worlds
There an interaction between embedded belief systems and the postulation
of possible worlds, which is done though the uses of tenses, modals, etc.
To start with, consider a simplified case in which only two belief
systems are involved, the speaker's and Sam's:
Sam thinks John had an affair with Bill's wife.
John's belief system isn't involved, since only his actions, not his
thoughts are involved. Similar to above, we have the possible beliefs of the speaker
as:
1 WifeOf(Bill, Person1)
2 Believes(Sam, \WifeOf(Bill, Person1))
This leads to three interpretations:
1 -- "But he (Sam) doesn't realize that's who she is".
2 -- "He doesn't realize that she's really George's wife"
1 2 -- the normal interpretation in which everyone agrees she's
Bill's wife
Notice that all of this is orthogonal to the distinction between "Sam
thinks..." and "Sam knows..." since that distinction is based on the
speaker's beliefs about whether the affair really happened or not, not
his beliefs about the identity of the individuals involved.
Now consider the closely parallel sentence:
"Sam thinks John will have an affair with Bill's wife".
The introduction of a future tense adds a new set of ambiguities. I
claim this happens in any situation where the embedded sentence creates
a new modal context, whether through a future tense, hypothetical,
modal (e.g. "can", "could") or through the implicit possible world
created by verbs such as "want", "expect", etc. when the embedded
sentence is in infinitive and therefore shows no explicit tense or
modal marking. Consider the possible interpretations of this sentence
when it is in answer to the question:
What does Sam think will happen when Bill's divorce finally comes
through and he gets remarried?
The phrase "Bill's wife" is now ambiguous in a new way. Even if the
speaker and Sam agree about all the facts, it could mean "the woman who
is now Bill's wife" or "the woman who will be Bill's wife" (in the
possible world indicated by "will have"). As a simplification (instead
of going to a modal logic), consider the predicate WifeOf as having an
argument indicating a possible world. We will simplify by having two
worlds, "Now" and "Then".
Theoretically there should be four possible beliefs:
1 WifeOf(Bill, Person1, Now)
2 WifeOf(Bill, Person1, Then)
3 Believes(Sam, \WifeOf(Bill, Person1, Now))
4 Believes(Sam, \WifeOf(Bill, Person1, Then))
However combinations involving 1 and 2 simultaneously or 3 and 4
simultaneously seem unreasonable interpretations of the sentence. Of the
remaining possibilities, four seem to be valid interpretations:
1 -- The speaker is identifying the woman, while Sam doesn't know
anything about whose wife it is (although the way I worded
the question makes this less likely)
4 -- Sam expects an affair with the Then wife
1 3 -- the usual agreement by everyone referring to the Now wife
2 4 -- agreement on a different set of facts
Only four others would meet the restriction of not having a single belief
system identify the same person as both the old and the new wife.
These seem not to be valid interpretations of the sentence as worded,
but demand a more specific wording:
2 -- Sam thinks John will have an affair with the woman Bill is going
to marry.
3 -- Sam thinks John will have an affair with the Bill's old wife.
1 4 -- Sam thinks John will have an affair with the woman he expects
Bill to marry, but who is really his current wife.
2 3 -- Sam thinks John will have an affair with the woman Bill is going
to marry, but he thinks she's Bill's current wife.
The net result of all this is that there are four interpretations instead
of three for the non-modal context. In Barbara's original example, there
is a single modal ("want"), and I suspect it will increase the number of
valid interpretations from 14, but only by a few. I need to think more
about the general formula.
---------------
Traditional opaque and transparent contexts
The sentence "John wants to marry Bill's wife" has the same kind of
ambiguity as "Sam thinks John will marry Bill's wife", (in fact
in a transformational analysis, the deep structures would be much
more similar than is apparent on the surface). What about the
The sentences:
John wants to marry the prettiest girl in the world
John wants to marry a Norwiegan
The first seems exactly analogous to the "Bill's wife" case. There is a
definite referring phrase, which can either be in John's belief system
or the speaker's, and can either apply in the current world or the
possible world implied by the "want".
The second is slightly different. Since it uses an indefinite noun
phrase "a Norwiegan". The two classical interpretations can be
paraphrased:
"John wants to marry some specific person who I describe as a
Norwiegan"
"John wants it to be the case that he will marry someone who can
be described as a Norwiegan"
What seems to be at stake is not whether or not some particular person
is or is not Norwiegan now or at the time they marry, (although this was
the issue in analyzing "Bill's wife"). It is on whether the speaker
believes that the person is identifiable now, or whether Bill believes
she will be identifiable at the time of the wedding.
Note that identifiability is a belief which is not equivalent to
existence. Consider the case of:
"There are three people in the room: one of them is a murderer. The
murderer was born in... and smokes cigars and...:"
In this case there is a conceptual entity for the murderer (a constant
in the notation we have been using here), and the belief system includes
a number of predications about that individual, including his existence,
but not his identifiability. I believe this is a fundamental primitive of
belief systems which cannot be reduced to notions of existence and
effective test.
I claim that the Norwiegan case is exactly parallel to the "Bill's
wife" case, with the relevant beliefs:
1 Identifiable(Person1, Now)
2 Identifiable(Person1, Then)
3 Believes(John, \Identifiable(Person1, Now))
4 Believes(John, \Identifiable(Person1, Then))
Because of the use of an indefinite phrase, it is the indentifiability
rather than the quality of being Norwiegan which is at stake. (I
haven't thought through the interactions which would come from
considering Norwieganhood as a property which can change over
time). The interpretations are therefore:
1 -- Traditional transparent reading, but could be extended with
"but He thinks she's Swedish"
4 -- Traditional opaque reading, but could be extended with
"but he doesn't realize that Norway never existed"
1 3 -- Transparent reading with agreement by everyone
2 4 -- Opaque reading with agreement by everyone
-----------
also I want to thiink some more about the interactions between
existence and identifiability.
∂23-Dec-76 1401 TW via MAXC addendum
looking over the last few lines, I realize I haven't dealt enough
with the interaction between identifiability and predication --
between believing that she is identifiable and
believing that she is Norwiegan. I'll revise it after I have
more chance to think about that example.
∂24-Dec-76 0249 PMF
∂24-Dec-76 0041 JMC Imlac
<ctrl><break> doesn't work to stop typeout and <break>W doesn't turn off
who line. Is this a feature?
[<ctrl> break doesn't work. <break> w works for me.]
∂24-Dec-76 1242 JAB via AMET accounting
I would like to talk to you sometime soon about accounting. What I would
like to do is to starting running my ispy program in parrallel with the
existing version starting a day or so before the new year. It seems like
the most convenient time in the near future. Once that is done the
problems of conversion can be taken care of. I will be picking up my
new used car today (I hope) and this shouldfix the problem of getting me up
there on some sort of reasonable basis.
Sounds fine to me. Talk to Jeff too.
∂27-Dec-76 2123 TOG ACCOUNTS
IN ANSWER TO YOUR QUESTIONS:
1)TODD GLASSEY(TOG)
2)AN OFFICE(IF AVAILABLE),AND 50 K OF MEMORY
3) THE LAB IS LOW ON HARDWARE PEOPLE AND LOW ON FUNDS
∂28-Dec-76 0029 TOG ACCOUNTS
TODD GLASSEY
991 BORANDA
MTN.VIEW,CA. 94040 ,968-4275
NO CONECTIONS AT THIS TIME.
I PROPOSE TO FURTHER MY KNOWLEDGE OF AI PROGRAMMING AS WELL
AS HARDWARE TECHNOLOGY.
AT ONE TIME I WAS WORKING FOR TED(APPROX 2 YEARS AGO)BUT THE FAMILY
MOVED TO SAN TROPEZ,FR.(THAT WAS ABOUT 3 MONTHS AFTER YOU CAME BACK
FROM JAPAN) SO HAVING RETURNED RECENTLY I AM INVESTIGATING
THE POSSIBILITIES OF GETTING A NEW ACCT.(AS I SAID I THOUGHT I WAS
WORKING FOR TED HOWEVER I THINK LESTER WOULD KNOW FOR SURE,AS HE OPENED
MY ACCT.THEN.
TODD
I'm sorry, but there is no justification for making you a user.
Please don't use the machine unless and until you have something
useful to the Lab to do and can get someone to request an account
on your behalf with a convincing argument that the Lab will benefit.
The request is not just a formality and will be looked at critically.
Please delete your files.
∂28-Dec-76 1059 FTP:Nilsson at SRI-AI proposed seminar
Date: 28 Dec 1976 1058-PST
From: Nilsson at SRI-AI
Subject: proposed seminar
To: jmc at SU-AI, eaf at SUMEX-AIM, buchanan at SUMEX-AIM,
To: davis at SUMEX-AIM, engelmore at SUMEX-AIM, ccg at SU-AI,
To: tw at SU-AI, les at SU-AI, luckham at SU-AI,
To: nmartin at SUMEX-AIM
cc: nilsson, friedland at SUMEX-AIM, moore at SU-AI,
cc: wilkins at SU-AI
I am proposing to organize a seminar on automatic problem solving as
described below. I would be interested in hearing about ideas for topics
from you and/or your students.
Nils Nilsson
SEMINAR ANNOUNCEMENT
WINTER QUARTER, 1977
CS 320
ARTIFICIAL INTELLIGENCE SEMINAR:
RESEARCH IN AUTOMATIC PROBLEM SOLVING
ORGANIZER: Nils J. Nilsson
TIME AND PLACE: Mondays
Serra House Conference Room
3:30 pm
(First meeting January 10,1977)
Several ongoing Ph.D. dissertations as well as other project work
in Artificial Intelligence involve research in Automatic Problem Solving.
Examples include work in automatic theorem proving, automatic programming,
expert systems and common sense reasoning systems. The purpose of the
proposed seminar is to encourage discussion of the various ideas being
pursued and to permit us to find out what each other is doing.
The seminar will meet once a week, and can be taken for one unit of
credit. Each week a volunteer speaker will talk about his/her research.
It is possible that some topics will take more than one meeting to complete.
If you are interested in participating and would like to volunteer
to discuss your project, please let me know as soon as possible. We
especially need someone willing to start the series off on Jan. 10.
Nils Nilsson
SRI Phone: 326-6200 ext. 2311
ARPANET: Nilsson @SRI-AI
-------
I think I would like to give a seminar entitled "Problem solving,
pattern recognition, and parsing", but not till the middle of the
quarter. Dave Wilkins should give a seminar also.
∂28-Dec-76 1212 RDR
DEC shananigans
The letter to the University counsel sounds like just what we need.
What ollows isn't exactly the same topic,
but I think it comes close. I forwarded a copy to Moon@mit-ml
too, because of something he said. Maybe if enough people scream
or make casual complaints, DEC will listen. Could we write to
Copy 'N Mail? Is that appropriate?
∂23-Dec-76 1534 FTP:Geoff at SRI-AI Sound all to familer??
Date: 23 Dec 1976 1527-PST
From: Geoff at SRI-AI
Subject: Sound all to familer??
To: REG at SAIL, RDR at SAIL, JBR. at AIC, MMcM at SAIL,
To: Dale at ISIB, Alfvin at ISIB, Lieb at ISIR1,
To: JMetzer at ISIR1, Feinler at OFFICE-1
Date: 23 Dec 1976 1516-PST
From: Lynch
Subject: Kl 1090T situation report
To: Raphael at OFFICE-1, Hart at SRI-AI, Russell at ISI,
To: Carlson at ISI, Blue at ISI, McKinley at ISIB, Ellis at ISIB,
To: Nielson at SRI-AI, Goldberg at SRI-AI, Norton at OFFICE-1
cc: System Staff:, Lynch
I hesitate to bring all this crummy news so close to Christmas, but
I thought I would share some of my experiences with you so we can
all be prepared for some pain.
DEC is being very slow in delivering what they promise to do.
I have been predicting a Feb 1, 1977 update for the SRI KL-1090T.
That was based on DEC delivering everything to me by 1 Jan 1977.
DEC is not going to make it. They are going to fail in 3 areas.
1) The ARPANET interface will not arrive until the end of
February (at best). They have just this week produced
the first production model of it and cannot have more
done through production until later.
2) I have ordered 96 local terminal lines. DEC will deliver
32 lines and says that the rest will not be delivered
until as late as June 1977. The major holdup is getting
the DH11 boards from the PDP-11 product line. Also there
is still some doubt in my mind that a single front end
PDP-11 can really handle that many lines effectively, but
that is a performance issue that will only be able to be
solved after the 96 lines actually arrive.
3) More than 256K of physical core has never worked on the
TOPS20 system. There are KL hardware mods to be made,
Front End software mods to be made, diagnostic software
mods to be made, Kl microcode changes to be made, etc.
DEC thinks that it has solved the technical problems
in this area, but it does not have a production version
of anything yet. What they have working now is highly
patched hardware and software. They feel that they
will have the mods in shipping shape by the 19th of January.
In spite of all this DEC is shipping "a system" on Monday, 27 DEC 76.
The main purpose of this is to get their internal books to make
somebody look good. I am adopting the stand with DEC that they
are being a bit childish in all this and that they should keep
the hardware there until they get a system together that at
least solves the >256K problem. (I have ordered 512K and expect
to order an additional 1 million words very shortly). I expect
that when DEC ships the mods for this they will also send an
expert to install it. I have asked them to send Bob Clements
and it looks good for that.
I have told DEC very plainly that I will not pay a cent until
all the hardware and software that was ordered is installed
and working satisfactorily. They understand this.
Meanwhile there is the user community to be reckoned with.
I do not want to layout a detailed contingincy plan here,
but smply it looks like the biggest medium term problem is
terminal access. The only straightforward solution appears
to let the SRI internal users use the KA system for TELNETting
to the KL system once the ARPANET interface is running in late
February. That will require ARPA's approval. This will take
up some of the KA's cycles for a few months running a few dozen
users in TELNET.
It certainly appears that the installation and transition to
the KL will not be very smooth. I am sorry for this as I'm
sure all of you are. If any of you have questions or suggestions
please flood me with them.
Dan
-------
-------
Please check with me before you forward things of mine. I very much
wanted Ralph to get the facts absolutely straight before sending it
outside Stanford. I fear I have been unfair to D.E.C. in some
respects and have neglected to criticize others. If they see it in
a wrong form, they will be naturally inclined to seize on whatever
criticism is unfounded and ignore the well-founded criticism.
∂28-Dec-76 1215 RDR via AMET
also maybe you know somebody at CMU who may well still lack their DH11
ports and core.
∂28-Dec-76 1634 PMF
∂28-Dec-76 0020 JMC
Once in a while, the WHO line covers the current line.
[ Thats because it lost the positioning command char for the who line.]
∂28-Dec-76 1954 RDR via AMET
No, no, I didn't forward YOUR message. I realize that wasn't done.
I forwarded the Lynch complaint to you, and Moon. It had already been
much forwarded, but seemed to be a good thing to make people aware of.
Fine.
∂29-Dec-76 0134 PMF Typing <call> at an Imlac.
Doing <ctrl> <call> does the right thing when the system thinks its talking
to an imlac instead of a datamedia.
How does that helpp? Is there any way of making it think it's talkin
to an Imlac when it is in a user progrr prog ignoring <call>?
∂29-Dec-76 1114 FTP:Nilsson at SRI-AI Seminar on SRI-AI Research
Date: 29 Dec 1976 1114-PST
From: Nilsson at SRI-AI
Subject: Seminar on SRI-AI Research
To: jmc at SU-AI, buchanan at SUMEX-AIM, davis at SUMEX-AIM,
To: engelmore at SUMEX-AIM, ccg at SU-AI, tw at SU-AI,
To: feigenbaum at SUMEX-AIM, lederberg at SUMEX-AIM,
To: les at SU-AI, luckham at SU-AI, nmartin at SUMEX-AIM
cc: nilsson, garvey, hendrix
We are organizing a special seminar whose purpose is to acquaint
members of the Stanford AI Community with AI research at SRI. Here
follows an announcement of the seminar.
Nils Nilsson
SEMINAR ANNOUNCEMENT
WINTER QUARTER, 1977
CS 229
TOPICS IN ARTIFICIAL INTELLIGENCE:
ARTIFICIAL INTELLIGENCE RESEARCH AT SRI
ORGANIZERS: Tom Garvey, Gary Hendrix, Nils Nilsson
TIME AND PLACE: Thursdays
Mc Culloch 128
4:15 pm
(First meeting January 6,1977)
The SRI Artificial Intelligence Center is involved in a number
of AI research projects ranging from natural language understanding to
automatic scene analysis. The purpose of this seminar is to describe
highlights of this research. The seminar can be taken for one unit of credit.
Each week an SRI researcher will describe one of the projects.
(Some projects may take up more than one meeting.) At the first meeting,
Dr. Peter Hart, Director of the SRI Artificial Intelligence Center,
will talk about "A Computer-Based Consultant for Mineral Exploration."
Some possible future topics and speakers are as follows:
Advanced Industrial Automation (Charles Rosen, David Nitzan)
Handling Uncertainty in a Rule-based System (Richard Duda)
Natural Language Access to Distributed Data Bases (Earl Sacerdoti)
An Intelligent Data Base Access Program (Daniel Sagalowicz)
Natural Language for Information Retrieval (Gary Hendrix)
Potential Applications of AI to Data Base Management (D. Sagalowicz)
Overview of SRI Natural Language Research (Don Walker, Ann Robinson)
The Use of Focus in Dialog Understanding (Barbara Grosz)
Experiments in Speech Understanding System Control (Bill Paxton)
Integrating Knowledge in Partitioned Semantic Networks (G. Hendrix)
Dependency Syntax (Jane Robinson)
Current Research in Computational Linguistics (Bill Paxton)
Vision Research at SRI (Marty Tenenbaum, Tom Garvey)
Automatic Aids to Cartography (Harry Barrow)
Range and Relectance Data for Scene Analysis (D. Nitzan, R. Duda)
-------
∂30-Dec-76 1450 LES
∂30-Dec-76 1424 FTP:Stefik at SUMEX-AIM AI lab account Request
Date: 30 DEC 1976 1424-PST
From: Stefik at SUMEX-AIM
Subject: AI lab account Request
To: les at SAIL
cc: stefik
Dr. Earnest,
I am a 4th year grad student in Computer Science
on the MOLGEN project under Prof Feigenbaum and use SUMEX-AIM for
most of my computing needs. Currently, I am working on a draft of
a thesis proposal which will become a Stanford CS Report and would
appreciate access to the superior pub, edit, and printing facilities
in use at the AI lab.
Would it be possible to arrange for an account on your machine
which I could use for these purposes? I would like to continue using
it for various papers and the thesis itself from now until June 1978.
I will continue to use SUMEX for big files and programming so that my
space and computing requirements will be modest.
Presuming that this can be arranged, I have three additional
requests.
1. I have a Data-media & 1200/150 modem at my home that was provided
by MOLGEN. I would like to make the "AI-lab" modifications for
reversing blink and boldface modes. Who can I talk to about this?
2. Can I have access to the AI lab dial-up numbers?
3. How can I get the manuals for PUB, a suitable editor, FTP, and
the EXEC?
Thanks,
Mark Stefik (Initials MJS)
STEFIK@SUMEX
-------
∂30-Dec-76 1550 DON JARGON guests
I've spoken to Jeff, and he says there is indeed no way for a network
user to FTP a file to us without an account. So, which way should we
go--two more guest accounts, or permission for two more people to use
Marc Crispin's account? (Or a combination of these two choices?) For
the record, the two people in question are GLS (Guy Steele, Jr.) and
RMS (Richard Stallman).
∂30-Dec-76 1911 WP Winter term:
I'd like you to supervise a CS390, reading and research; if this is
possible, we should meet and discuss subjects and details before monday.
Please mail me a date,
Wolf.
Friday 3pm if that's ok.
∂31-Dec-76 2044 WP CS390
Sorry, but I didn't read my mail in time to make the 3pm on Friday.
I'll be around Sunday the whole afternoon and evening (starting 3pm).
Happy New Year,
Wolf.
∂31-Dec-76 2110 PMF
<ctrl><break> now does a hold. <ctrl><clear> doesn't work but
<ctrl><break> toggles hold.
∂01-Jan-77 0217 PMF <ctrl><break>
The fix is to the imlac program. You will have to reload. (be sure to logout
first).
∂01-Jan-77 0226 PMF reloading an imlac.
Logout. Wait 10 sec. or so. Push the stop button on the back of the imlac. then
hold "at 40" and push start. Now type <shift>c fix <shift>m wait a few seconds
then type <ctrl><top><shift>s. The loader should then start.
∂01-Jan-77 0352 JAB new spy
To: JMC, LES, EJG, JBR, GFF, RDR
A new spy is running in parallel with the old. It complained alot
when it was first put up resulting in numerous messages on the console
but that has been fixed. If it does complain it will precede it with
ISPY ..... to indicate just who is upset.
The old spy has been changed to check for the new one and if it is
missing will start up a job to get it going again. The data collected
is stored in act,jab.
∂01-Jan-77 0402 JAB new spy
To: LES, JMC
With the new spy reliably (I hope) collecting data I think the next step
is to decide what form to keep the data in over the long term. Unfortunately
this data can be quite voluminous. I hope to be up at the lab often and
can move much of it to tape if that seems warrented.
If you would like to talk about where we go from here let me know. I have
a car now and can therefore be more definite about my schedule.
Do you understand what JAB has done and what we should do now?
∂01-Jan-77 1733 LES
∂01-Jan-77 1210 JMC
Do you understand what JAB has done and what we should do now?
No, though I sent him a message requesting the information earlier.
I have re-requested that he come see me.
∂03-Jan-77 1045 PMF
Do you need a TA for your course?
There has been a last minute change. CS258 will be taught by
Zohar Mannna. I had planned to teach it without a TA, but he
may want one. I will teach CS206 again in the Spring and will
need a TA.
∂03-Jan-77 1629 FTP:Dbrown at SUMEX-AIM Re: MCCARTHY TEACHING SCHEDULE REARRANGEMENT
Date: 3 JAN 1977 1630-PST
From: Dbrown at SUMEX-AIM
Subject: Re: MCCARTHY TEACHING SCHEDULE REARRANGEMENT
To: Feigenbaum
cc: jmc at SAIL
In response to your message sent 3 JAN 1977 0803-PST
Ed, Ok, Zohar for 258 in Winter. JMC for 206 in
Spring. Mike Farmwald has volunteered to Ta for
John in 206. ←Denny
-------
∂03-Jan-77 1917 ME
To: JMC, PMF
Use TTY DM128 on Imlacs to have all chars displayed correctly.
∂03-Jan-77 2140 REM via AMET Heavy use in Dec., light use forthcoming.
During winter vacation there was the usual lull in computer use,
but I guess I took too much advantage of that lull (over-used the computer).
Now that school is resuming, and after getting your note about my over-use
in December, I plan to reduce my usage to a level comensurate with my
benefit to the lab (principally some POX enhancements).
∂04-Jan-77 0404 PMF
∂03-Jan-77 1119 JMC
There has been a last minute change. CS258 will be taught by
Zohar Mannna. I had planned to teach it without a TA, but he
may want one. I will teach CS206 again in the Spring and will
need a TA.
[I would be interested.]
∂04-Jan-77 0515 PMF Imlac documentation
To: ME, JMC, RWW
Imlac.pmf[up,doc] describes the new imlac procedures. Feel free to make changes
or additions.
∂04-Jan-77 1530 RWW FOL
To: FOL.DIS[FOL,RWW]:;
I would like to start ?weekly? meetings on what everyone is
doing on FOL and related topics. Thus I would like everyone to
sent me convient times so I can attempt to find a time good for
everyone. Thanks.
rww
∂04-Jan-77 2103 TED
There is a deplorable tendency to totally uninformative X is down,
Y is dead notices. The users would be less anxious if a bit
more effort to be informative were made.
IF YOU WANT TO KNOW MORE, YOU SHOULD READ THE LOG. LONG WINDED
EXPLANATIONS ONLY CLUTTER UP THE LOG IN MESSAGES, CAUSING REALLY
IMPORTANT ONES TO GET IGNORED.
∂05-Jan-77 0924 FTP:Nilsson at SRI-AI Problem Solving Seminar
Date: 5 Jan 1977 0924-PST
From: Nilsson at SRI-AI
Subject: Problem Solving Seminar
To: JMC at SU-AI
cc: Nilsson
John,
Thanks for your response about my problem solving seminar.
Let me know when you'd like to talk. I'll get in touch with
Dave Wilkins.
Nils
-------
∂05-Jan-77 1154 DCO
To: JMC, RWW
If you havent already seen it, you may be interested in a recent
note by Hartmanis and Hopcroft in the latest SIGACT news. They observe
that there are naturally occurring problems in computer science which
are independent of set theory - for example that there are algorithms
whose running time is independent of the axioms of set theory, as is
a relativized version of the P = NP problem.
∂05-Jan-77 1544 FTP:Buchanan at SUMEX-AIM Computer Forum this month
Date: 5 JAN 1977 1543-PST
From: Buchanan at SUMEX-AIM
Subject: Computer Forum this month
To: feigenbaum, mccarthy at SU-AI, winograd at SU-AI
cc: buchanan
00100
00200 The AI session for the computer forum is
00300 January 27 at 1:30. You have a 20 min slot (15 min
00400 presentation plus 5 min for questions) to use as you like.
00500 Will you please send me a note before Friday telling me
00600 whether you will speak or you would like to have a graduate
00700 student present his/her work. I would also like the name
00800 of the student and a title for the talk to put on the program.
00900
01000 Thanks,
01100 Bruce
-------
∂06-Jan-77 1539 LES Home phone lines
To: DRB, TOB, JJ, CCG, EK, DCL, BPM, DCO, JP, ALS
CC: JMC, HVA
Because of recent telephone tariff changes and the resultant costly
charges for connect time on business lines, we have told the telephone
company to disconnect all the business lines in peoples homes (including
yours). Disconnect should happen within about 10 days.
Assuming that you wish to continue using a home terminal, you may either
use your regular home phone or have another personal line installed. If
you use your regular home phone, the lab will cover half the cost of 60
unit service. If you have an additional line reconnected, the lab will
cover the cost of installation and the full 60 unit service. Any
additional charges other than toll charges for lab business will be your
own. In either case, it will be necessary to bring the phone bills in to
be reimbursed out of petty cash.
Since the legality of this move may be open to question, please try to
avoid provoking Ma Bell. In particular, before the telephone remover or
installer appears, please disconnect the computer terminal and any jacks
that have been installed. It might be better still to put the terminal
somewhere else temporarily. Since you can now order a new phone with a
jack at no additional cost, I suggest that you request it that way since
it makes the terminal connection easier.
I regret having to complicate your life this way, but the current policies
on business lines are discrininatory and we can't afford them. The
question of whether or not these lines should in fact be business lines
is arguable (e.g. is a graduate student doing research in business?),
but I would rather avoid the argument if I possible.
Les
Good memo.
∂06-Jan-77 1929 FTP:ELLENBY at PARC-MAXC Returned Your call
Date: 6 JAN 1977 1929-PST
From: ELLENBY at PARC-MAXC
Subject: Returned Your call
To: JMC at SU-AI
John,
got your message too late to ring you and will be tied up
away from PARC in meetings most of Friday. SndMsg me if
its convenient.
John.
-------
∂07-Jan-77 1159 PMF
You might want to reload your imlac. Several new features. Main one
being an arrow points to the current line being edited and to attached lines
in E.
Thanks.
∂08-Jan-77 2331 RWW conditional
The problem was one we discussed before. The implemented version
insists that the predicate symbol or opsym be given in prefix form.
I consider this a dubious feature but can't remember why it "has"
to be that way. the fix appears in corky[fol,rww]. i.e.
λu.u=term doesnt work but
λu.=(u,term) does.
sorry. i'll try to remember why this strangness.
rww
∂08-Jan-77 2340 RWW conditional substitution
I was just about to write the section of the manual about
conditional substitution. Could you once again repeat your
idea of how it should work. (I hope to write it up and implement
it this week).
rww
∂09-Jan-77 0727 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 9 JAN 1977 0841-EST
Sender: PRATT at MIT-AI
From: PRATT at MIT-AI (Vaughan Pratt )
To: JMC at SU-AI
Message-ID: <[MIT-AI].47657>
I don't know how strongly you feel about defending your baby (LISP)
at Stanford as a departmental language, but if you are interested
there is a plug for LISP on AI:PRATT;LSPLUG > . EECS here is in the
process of figuring out what it as an academic department needs as
a department-wide computing facility, with emphasis on computers as
an educational tool. The way I see it, we are fortunate that ANY
single language exists around which a water-tight case can be built,
otherwise we would probably not be on speaking terms to each other
for years after deciding on a language or languages. As it is, I believe
our non-LISP users are sufficiently poorly served by the alternatives
that the opposition will be minimal. The reason I am writing this
paper at all is that LISP is incredibly undersold
around here, and is widely regarded by half the faculty as "that
arcane language you are forced to use when your data is irregularly
structured." Somehow or other LISP users do not make good publicity
agents.
Cheers
Vaughan
∂10-Jan-77 0033 RWW
I have fixed SUBPARTs to work with conditional expressions,
but have found an ambiguity in the grammer so BEWARE!!!!
If 1. IF P(X) THEN P(X) ELSE P(X)
then ASSUME IF 1:#1 THEN 1:#1#1 ELSE X=X
returns IF P(X) THEN P(X) ELSE (X=X)
not (IF P(X) THEN X ELSE X)=X
because as recorded in the manual a WFF subpart designator
always returns either a wff or the first ATOMIC!!!! wff it finds.
This is not a good convention but is to hard to fix this round.
To fix it in the obvious way leads to other ambiguities, etc....
rww
∂10-Jan-77 1441 JBR
∂07-Jan-77 0019 JMC Telnet from datamedias
To: JBR, ME
I notice some people come in on Datamedias and go out on Telnet.
How expensive is this for us in system load? Shouldn't we make
them use the TIP?
I guess we should ask them to use the TIP, as TELNET is always scheduling
on and off as characters irregularly come in.
∂10-Jan-77 1552 RPG
∂09-Jan-77 1658 JMC LSPLUG
Vaughan Pratt has produced a brief for LISP as a departmental programming
language that I have FTPed as LSPLUG[W77,JMC]. It is in some M.I.T.
PUB like form. Do you know how to print such things?
Well, there is a program called TJ6PUB, written by Mitch Model, which is
reputed to convert, however it doesn't exactly work on LSPLUG. It produced
LSPLUG.PUB, which produced many PUB errors. One could either coerce Model
into fixing TJ6PUB, or edit LSPLUG.PUB. Not knowing PUB too well, I'm not
sure whether there were many error causes or one which propagated.
-rpg-
∂11-Jan-77 1015 RWW FOL
CORKY.DMP IS FIXED ON W77 AND FOL IS FIXED ON SYSTEM.
RWW
∂11-Jan-77 1016 RWW FOL
PS THE DIFFICULTY WAS AN INCONSISTENCY IN THE SOURCE CODE DUE TO
AS YET UNDEBUGED TAUTEQ CODE.
RWW
∂11-Jan-77 1311 FTP:Boyer at SRI-AI Our new theorem prover
Date: 11 Jan 1977 1309-PST
From: Boyer at SRI-AI
Subject: Our new theorem prover
To: LUCKHAM at SU-AI
cc: JMC at SU-AI
We have been working on a completely new version of our theorem
prover for recursive functions. It finally came to life this
weekend, and to our great surprise, managed to prove the correctness
of a simple optimizing compiler for expressions.
We know Cartwright's theorem prover proved the correctness of
the McCarthy-Painter compiler "with a reasonable amount of programmer
guidance".
The theorem we proved is that if you execute the compilation of the
optimization of an expression then the result left on the top of
the machine's push down stack is just the EVAL of the unoptimized
expression. (Unlike the McCarthy-Painter machine, ours has
a stack instead of registers for temps and results.) The optimizer
simply does "constant folding", i.e., evaluates expressions when
their args are constants.
To get the theorem prover to prove the above we must have it prove
4 lemmas first. The lemmas are quite beautiful in their own right
and concern the following: That executing the concatenation of two
instruction sequences yields the same final stack as executing
the first sequence and then the second; that the compiler is correct
with respect to eval if you don't optimize; that the optimizer
always produces a well-formed form; and that the eval of an optimized
form is equivalent to the eval of the unoptimized one. All of the
above are proved automatically by induction etc. Once proved, the
main theorem is proved immediately by application of the above lemmas.
It should be noted that our proof of the correctness of the compiler
(without the optimizer) is entirely automatic except for its reliance
on the first lemma cited above. The other two lemmas needed for the
main theorem only serve to get the optimizing phase in.
We are curious to know whether this proof is an advance of the state of
the art. Can you, on the basis of the above sketch, contrast it to
Cartwright's proof?
Also, would you please send us a copy of his thesis if available?
We are now in a position to give a talk on our theorem prover if you
would like. We have mailed you both a copy of the above proofs.
J Moore and Bob Boyer
-------
I would like an informal discussion of the theorem prover. It sounds
like an advance all right. Apart from that, Cartwright's thesis gets
total correctness of LISP nicely into first order logic, and I have
an extension of his results that put proving non-termination into the
same framework as well as what I think is a slight cleanup of his
results. My ideas concern the logical formalism - not heuristics,
but now for the first time, I understand a good first order theory of
partial functions. I do not exclude the possibility that others have
understood it previously.
Cartwright is here for a week or so, and we should meet while
he is here.
∂11-Jan-77 1910 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 11 JAN 1977 2108-EST
Sender: PRATT at MIT-AI
From: PRATT at MIT-AI (Vaughan Pratt )
To: rpg at SU-AI
CC: jmc at SU-AI
Message-ID: <[MIT-AI].48685>
Fascinating! John didn't tell me that Stanford was thinking about using
Maclisp (or that John was using it) when I visited in November.
Do you have CGOL available at Stanford? If not I can ship you a
version of it written in MACLISP (the source is in CGOL needless to say
but its trivial to get a translation via CGOLREAD; also CGOLPRINT
exists). Main advantages of CGOL over MLISP:
CGOL can be loaded into an ordinary MACLISP without notice;
CGOL notation can be used at the console just as well as in a file (I only
used MLISP I so I don't know what the story is on MLISP II in that
respect);
You can switch back and forth between CGOL and LISP notation either
in a file or from the console (independently of each other, so that
a console user speaking CGOL can read a file without having to know
whether the file is written in CGOL or LISP) just by typing (CGOL)
and EXIT$
You send files to the compiler without knowing whether they are LISP,
CGOL or a mixture; the compiler sorts all that out automatically;
CGOL is (blowing my own horn here) probably the best extensible language
available, offering fast incremental extensibility with efficient
parsing guaranteed. MLISP I is not very extensible, while
MLISP II is extensible but no guarantee of fast parsing is given
because it relies on back-up to sort out local ambiguities. CGOL
does no backing up.
(Hope the truth-in-advertising boys don't get their hands on this.)
Oh, I just remembered the amount of time Richard Weyhrauch spent
struggling with MLISP when implementing the syntax for FOL.
I believe he's long since given up on MLISP for that job and is using
his own parser. Steve Litvintchouk and I are implementing the
program-proof-checking version of FOL for the modal
axiomatization of programs I described in my talk at Stanford.
You've probably seen in my LSPLUG paper the account of how we added
syntactic sugaring to Litvintchouk's program with just a few hours
work. What I did not say (since it wasn't relevant to selling LISP here,
only to selling CGOL which wasn't my purpose in LSPLUG) is that we did
it using the sublanguage facility, which makes it almost
trivial to define your own little language, either with CGOL as
the default for any operators undefined in your sublanguage or with
nothing as the default. Further you can embed sublanguages within
sublanguages, defaulting outwards towards CGOL. It's
all remarkably pleasant and simple to use. See AI:PRATT;MSYN >
for the definition of the syntactic sugar for the modal proof checker.
Vaughan
I have indeed switched to MACLISP for my own work. I'll use it
in class too if I can get a version that works in TOPS-20 alias TENEX.
RPG can tell you the state of CGOL here; I haven't tried to use it,
because MACLISP was enough learning effort for the moment, but I
have one question about defining syntaxes. What about error handling?
That's what really killed the FOL use of MLISP's syntax reader.
I'm sending you my publication language and am also a bit reluctant to
teach three languages. That's why I dropped using RLISP and MLISP
in class. Also when we switched to ILISP, there were just too many
manuals. By the way, what's the MACLISP manual situation?
Corky Cartwright has just finished a thesis about proving
"Typed Lisp" programs correct. He has a prover, but what interested
me was that he really got proofs of total correctness entirely into
first order logic, and I have been able to extend his method to
proving non-termination. I need to look at your modal approach again,
but now it seems to me that vanilla-flavored first order logic is
just fine.
∂11-Jan-77 2020 FTP:Boyer at SRI-AI Meeting
Date: 11 Jan 1977 2020-PST
From: Boyer at SRI-AI
Subject: Meeting
To: jmc at SU-AI
cc: luckham at SU-AI, moore
We will be delighted to meet. Our daily schedule is extremely
flexible so propose a time that suits you. Bad times: 5-9pm
Wednesday and Thursday.
I hope we did not mislead you about what we had proved. It was
just the expression part, as in the McCarthy - Painter paper in
the AMS Applied Mathematics XIX. (Also as in Burstall, Structural
Induction, end of the paper compiler. I would ship you the proof
but it is on Suppes' machine. I believe you have an account there.
(if not I'll give you the password if you want). The file is
<moore>compile.ex.
-------
∂12-Jan-77 1005 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 12 JAN 1977 1305-EST
Sender: PRATT at MIT-AI
From: PRATT at MIT-AI (Vaughan Pratt )
To: jmc at SU-AI
Message-ID: <[MIT-AI].48906>
CGOL is set up so that you can implement any notation you want,
either temporarily or permanently. The only vested interest I have
myself in the CGOL language per se is a lot of CGOL code I have lying
around. However, the CGOL methodology IS something I see as being
both permanent and extremely useful; as a demo, I will implement your
language as soon as I get your write-up, that sort of thing being an afternoon's
work in GOT (the translator used for CGOL).
Error detection is excellent in CGOL because a role for each token is decided
the moment the parser gets its hands on it, not after reading more of
the input stream, possibly repeatedly as in MLISP 2, to figure out what's
going on. One sacrifices surprisingly little to this apparent limitation
of CGOL; for simple constructs there is no difficulty, and for more involved
ones that seem to demand lookahead I have worked out a style of programming
in which you "carry your indecision forward" with you as the input pointer
moves on. Because you can readily characterize exactly what you know
about the token you are staring at, even in the complicated cases, you
can catch errors the instant they arise, provided the absence of errors
is defined to be the existence of a remaining-input which when concatenated
with what you've read to date yields a legitimate program. (One problem
here is to make sure that not everything is legitimate, which is handled
in the language CGOL by avoiding having too many dual NUD-LED meanings
for tokens.) A careful theoretical treatment of these and similar claims
appears in my POPL I paper (SIGACT/SIGPLAN Princ. of Prog. Lang, Boston,
1973).
No doubt if I had the opportunity to revise this letter I would rephrase its
claims in a style less suggestive of Madison Avenue. In the meantime, this
is ole Show Biz signing off.
Cheers
Vaughan
∂12-Jan-77 1054 FTP:Moore at SRI-AI Our recent proof
Date: 12 Jan 1977 1054-PST
From: Moore at SRI-AI
Subject: Our recent proof
To: JMC at SU-AI, LUCKHAM at SU-AI
cc: BOYER
I have just added a one page comment at the beginning of the output
file explaining enough of our conventions to let you (hopefully)
follow the definition of the problem and the proof. In case you
have already read <MOORE>COMPILE.EX from the Suppes machine,
you should just read <MOORE>COMPILE.NOTE.
We did not get around to mailing you the copy of the output yesterday
because of the absence of such a note. I will see that it is
mailed today.
We will wait to send this preliminary version of the documentation
to others until we've had a chance to talk to you and Cartwright.
J
-------
∂12-Jan-77 1348 CJS
Richard Weyhraugh called in to say he felt rotten and wouldn't be coming in,
but he'll see you tomorrow.
∂12-Jan-77 2235 DSB
Is it true that you will be teaching C.S. 206, the LISP class, this
spring? Do you think I would get anything out of it, even
though I already know LISP?
∂13-Jan-77 0132 JMC
Use is heavy tonight. Is your use to AILAB advantage?
[REM - Yes, implementing overlays qua characters, will make it possible
to do RWG et al fancy overlays justified in paragraphs like other
stuff, unifying some techniques (the same thing can be done in all modes
instead of having to have different sets of macros for different modes) that
users have developed, allowing some things that prevously couldn't be done
at all (vectors inside words in justified text, using vectors
to simulate underlining beyond normal subscript/superscript range inside
justified text, such as large fractions, and also
allowing pretty square-roots that neither RWG nor HPM have successfully
created by previously-existing mechanisms in justified text despite their
great efforts and needs), and as a forerunner to foreward-reference overlays
in 2-pass mode that could be implemented this Spring.
Note that I have avoided doing any compute-intensive work tonite except
for one FAIL compilation of POX.FAI so far.]
∂13-Jan-77 0150 CLT mix
yes, I was learning about mix for 144a. I didn't think it would be a problem this
late at night. I am sorry if that assumption was incorrect. CLT
PS My reply is slow because I have never sent mail before.
Except when extremely inconvenient, please use LOTS for courses
for which AILAB is not explicitly specified. Tonight is ok.
∂13-Jan-77 1600 FTP:MRC at MIT-AI (Mark Crispin )
Date: 13 JAN 1977 1855-EST
Sender: MRC at MIT-AI
From: MRC at MIT-AI (Mark Crispin )
To: DFTP-USERS at MIT-AI
Message-ID: <[MIT-AI].49567>
Old DFTP(ODFTP on ITS, DFTP.OLD at SAIL) has gone away since CCA
has sloshed all old files to the new 203 Datacomputer, or so they
claim. Anyway, nothing exists oon the old Datacomputer any more.
∂13-Jan-77 2138 DCL MEETING ON NEW LISP PROVER
To: BOYER at SRI-AI, MOORE at SRI-AI, JMC, RSC, DCO
Our normal verification seminar time is Thursdays at 3.00pm.
Given that some of us will be at POPL conference in LA during
the first part of next week, THURSDAY 20th is the first
likely day. Is that suitable for all above? Especially Corky?
-David
∂13-Jan-77 2318 FTP:Moore at SRI-AI Re: MEETING ON NEW LISP PROVER
Date: 13 Jan 1977 2311-PST
From: Moore at SRI-AI
Subject: Re: MEETING ON NEW LISP PROVER
To: DCL at SU-AI, BOYER, JMC at SU-AI, RSC at SU-AI,
To: DCO at SU-AI
cc: MOORE
In response to the message sent 13 Jan 1977 2138-PST from DCL at SU-AI (Dave Luckham)
We are currently planning to talk to JMC and Corky and you at 2 pm
on Friday 14 Jan (tomorrow). This was scheduled Wednesday at JMC's
request. We will be happy to give a real talk on our work on the
date you suggested (20 Jan) if that is what you meant but we would
like to meet with you three tomorrow informally just to clarify the
connection between our stuff and Corky's and to hear JMCs understanding
of partial fns, which we don't handle yet.
J and Bob
-------
∂13-Jan-77 2332 LES CSDDIS.PRO
There is a budget on page 6.
What directory?
∂13-Jan-77 2348 LES CSDDIS
I think that I will be up all night working on it. I'll try to get a
nap and come in. After lunch would be better for me.
OK, when you quit leave me a copy and a note saying when you will be available.
∂14-Jan-77 0210 LES
I just chased off someone from IMSSS who was logged in as Bob Smith
∂14-Jan-77 0631 LES Display proposal
There are two copies of the proposal on your terminal. I have asked
Hersche to make 20 copies of the CSD research summary, which will be
Appendix B of the proposal.
I plan to go sleep some. When I wake up (probably around noon) I
will call the Lab to find out whether and when you want to discuss.
∂14-Jan-77 1405 LES
∂14-Jan-77 0216 JMC
Is PN one of the 3 new musicians we agreed to?
Yes.
∂14-Jan-77 1452 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 14 JAN 1977 1750-EST
Sender: PRATT at MIT-AI
From: PRATT at MIT-AI (Vaughan Pratt )
To: jmc at SU-AI
Message-ID: <[MIT-AI].49940>
How many terminals will LOTS make available initially? (Please dont
say "lots".)
LOTS now has 32 ports, and about 29 of these are available to users.
Our order was for 48, and the others will be delivered in March.
We intend to order another 16.
∂14-Jan-77 1609 FTP:PRATT at MIT-AI (Vaughan Pratt )
Date: 14 JAN 1977 1908-EST
Sender: PRATT at MIT-AI
From: PRATT at MIT-AI (Vaughan Pratt )
To: rpg at SU-AI, jmc at SU-AI
CC: GLS at MIT-AI, (FILE [PRATT;LISP SUGG]) at MIT-AI
Message-ID: <[MIT-AI].49976>
How are you planning to keep MACLISP up-to-date with MACLISP changes
here? Obviously you can just take all the MACLISP software from here
and forget about us and maintain it 100% yourself. However only death
and taxes are more certain than that your version and ours will drift
apart after a while. I would be sorry to see this happen, because I
often have occasion to move LISP programs around between sites (Stanford,
PARC and Edinburgh are 3 recent such sites) and it is a drag having to
write macros and diddle code to keep things shipshape between sites.
Getting FOL here is going to be a particular drag because of all that
highly system dependent LAP.
One solution that makes sense to me, if you want the
luxury of being able to grow your own offshoot of MACLISP without
having to abandon us completely is to treat modifications to LISP
and writing ordinary LISP programs on the same level, taking
advantage of LISP's nice "monotonicity", where you can just keep
adding things to LISP by reading them in from a file till the
environment looks the way you want it. CGOL makes some pretty radical
changes to the standard LISP environment, changing the listen loop,
the lexical syntax (completely different from standard LISP), and so
on without having to touch LISP's source code. Yet these changes
are all changes made using documented and supported LISP facilities,
which means that as each new version of LISP appears (even if it is
a radical revision such as BIBOP lisp was 3 years ago or NEWIO is
right now) I don't have to touch a thing in CGOL to keep it up to date.
Of course, if they tamper with something documented then I and all other
system users have a problem; fortunately, MACLISP has settled down
pretty well in the last couple of years in that regard (unlike our
TECO unfortunately).
Not all mods to MACLISP may be possible in this way (although
MACLISP is I think getting near the point where it is like
Rudy Krutar's ideal of a system built out of little n-port devices hooked
together (which I suppose is also like Jack Dennis' dataflow
architecture) allowing you to modify as much or as little as
you like by reconnecting ports and adding your own modules).
However, when you do run into a genuine difficulty in this
respect, MACLISP should be changed (probably at your end as long
as no one objects to the change at this end, though I can see
where pride may over-ride common-sense in such an arrangement)
so as to support your proposed modification without disturbing
the other MACLISP users.
I am fairly optimistic that in this way both ends can be
kept happy eating out of the one LISP, even as their requirements
diverge. Moreover, those of us at this end that want to use
what you have developed at your end (or vice versa) won't find
themselves in the ridiculous situation of having to ask you for
time on LOTS over the net to use your version of MACLISP but
can simply ship here those additions to LISP that they covet.
A neat spin-off of this is that if we can keep up this kind of
operation for say a couple of years it would make a quite
influential paper on how to structure things so as to keep
one universal language while catering to a diversity of requirements.
In a sense what's being done is all obvious, but I don't think
many computer scientists believe that this sort of thing is
possible on quite this scale. Moreover, once we've ironed
out the bugs in this two-node exercise, adding more nodes becomes
a matter of pointing to what's going on and waiting for
customers to appear.
Cheers
Vaughan
∂15-Jan-77 1426 DCO MEETING
To: RSC, JMC, DCL, MOORE at SRI-AI, BOYER at SRI-AI
I am afraid that I was at Berkeley all day Friday and only read the
messages about the Friday meeting now. Sorry I missed it. I hope
we can arrange for a seminar on the theorem prover.
∂15-Jan-77 1522 LES LSPLUG
I got LSPLUG.PUB through PUB, but notice that it is in LPT rather than XGP
format. For a small additional fee it could be fancied up.
For that I'll double your fee.
∂15-Jan-77 1532 LES Feinler request
Jake Feinler at SRI inquired awhile back about having an account for
light-duty access, such as swiping things from us. As I recall, I passed it on to you. Anyway, we
should give her an answer.
OK, I guess on Feinler.
∂15-Jan-77 1923 FTP:Boyer at SRI-AI meeting
Date: 15 Jan 1977 1923-PST
From: Boyer at SRI-AI
Subject: meeting
To: rsc at SU-AI, jmc at SU-AI
Thank you for the meeting Friday. J & I are going to give a presentation
on this Friday to our people at SRI from 10:00 to 12:00. It will be
far more organized than what we said at SU-AI. You are welcome to come.
I have been dwelling on Jmc's observation that the first order formula
for Flatten is sound (or for any recursively expressed function) provided
that the variable ranges over the sexprs. I had certainly never seen
the matter in such a light. The problem of embedding such
a theory in an automatic theorem prover comes down, in
my opinion, to the pain of checking that the formulas that one
wishes to substitute for the variables in the defining equation
are sexprs (in the case of flatten). Recursively, the problem
becomes one of knowing under what conditions one's parital functions
return nice objects and relieving those conditions with the hypotheses
of the theorem one is proving. In the past my principal pains in
in my abortive attempts at dealing with partiality have been oriented
around trying to rely on the continuous version of COND, say, which
is defined to return undefined if its first argument returned
undefined. However, one gastly effect of that, from the point of view
of automatic theorem proving again, was that the function bodies became
hideously infected with testing upon everyone, whether they returned
undefined. I am glad to know this approach. Provided our feeble support
continues, J and I hope to tackle adding partialness in a short while.
-------
∂15-Jan-77 2214 DEK
the service on lots is so much slower than at ai, i don't know how
to tell my students to use it when they have accounts e.g. in the
music program.
i have 100 students trying to use lots, perhaps more when you count the
3o or so watching on tv. there are lots of other classes using lots too,
and lots of volunteer hackers. the students have to wait hours to get
a console, and then the response time is so slow it sometimes types
only one character at a time; one student told me it takes
three minutes just to log off. what do you plan to do when MORE courses
use lots? this quarter it is just "pilot" runs... I know that the
memory hasn't all arrived yet, nor have all the display
terminals, but even so i can't see how the lots system can
be anything but swamped from now on. net result is that the
students will be happier using punch cards at scip, but they wont
be able to get accounts any more... if lots service were better,
i wouldn't hesitate to insist that cs144 students run on it. but as it
is, i don't want to, since it is surely no worse this year than in
the last 4 years cs144 students have been using mix up at ai. in factt,
the burden on you should be lighter now, since you now have a kl-10.
Well, we'll have to do our own chasing then.
When the memory comes, we'll have to evaluate LOTS and see how its
capacity compares with the requirements.
∂16-Jan-77 0501 PMF IMLACS
The new imlac program has 30 lines. Marty has changed the system to support more
and so you might like to add the statement "dm128=30" in your option.txt. I have
not been able to reproduce the imlac lossage you have been getting.